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Para Lee Peterson e Robert Davie 


Dedicatória 


Comentários sobre o livro 


Já conheço e tenho usado este livro há anos, e sempre o achei muito valioso como livro-texto para o ensino de redes 
de computadores, além de um livro de referência para profissionais da área de redes. Esta quinta edição conserva 
o valor básico das edições anteriores e aumenta a clareza da explicação sobre protocolos de rede na apresentação 
das mais atualizadas técnicas, tecnologias e requisitos das redes. Além de descrever os detalhes das redes do pas- 
sado e do presente, este livro motiva com sucesso a curiosidade, e possivelmente novas pesquisas, voltadas às 
redes do futuro. 


Stefano Basagni 
Northeastern University 


Peterson e Davie escreveram um livro fantástico para o mundo das redes de computadores. Este é um livro muito 
bem organizado, que possui uma abordagem de sistemas muito útil para compreender o “quadro geral”. Este livro 
é essencial! 


Yonshik Choi 
Illinois Institute of Technology 


A quinta edição de Redes de Computadores: Uma Abordagem de Sistemas é bastante adequada para o aluno sério 
de redes de computadores, embora também permaneça acessível ao leitor casual. O entusiasmo dos autores para 
com o assunto é evidente em toda parte; eles possuem um conhecimento profundo e atualizado dos problemas 
interessantes dessa área. Os autores explicam não apenas como os diversos protocolos funcionam, mas também 
por que eles funcionam dessa maneira e até mesmo por que certos protocolos são os mais importantes e interes- 
santes. Este livro também está repleto de pequenos toques de base histórica, desde o texto principal até os quadros 
“Onde eles estão agora” e os artigos descritos na seção de “Leitura adicional” de cada capítulo — estes dão ao leitor 
uma ideia de como as coisas chegaram ao estado atual. Em geral, este livro oferece uma introdução lúcida e es- 
clarecida sobre o uso de redes. 


Peter Dordal 
Loyola University Chicago 


Tenho usado Redes de Computadores: Uma Abordagem de Sistemas há mais de cinco anos em um curso introdu- 
tório sobre redes de comunicações, visando a alunos quase formandos e de primeiro ano de Mestrado. Passei por 
várias edições, e, com o passar dos anos, o livro tem mantido o que, desde o início, foi seu principal ponto forte, a 
saber, que ele não apenas descreve o “como”, mas também o “por que” e, tão importante quanto isso, o “por que 
não” das coisas. Esse é um livro que desenvolve a intuição da engenharia e, nesta época de mudanças tecnológicas 
rápidas, isso é essencial para se desenvolver a capacidade do aluno para tomar decisões informadas e projetar ou 
selecionar os sistemas da próxima geração. 


Roch Guerin 
University of Pennsylvania 


Este livro é uma introdução excepcional às redes de computadores, que é clara, abrangente e repleta de exemplos. 
Peterson e Davie possuem um dom para transformar as redes em conceitos simples e tratáveis, sem comprometer 
o rigor técnico. Redes de Computadores: Uma Abordagem de Sistemas luta para conseguir um equilíbrio excelente 
entre os princípios por trás do projeto de arquitetura de rede e as aplicações criadas em cima disso. Ele será muito 
valioso para alunos e professores de cursos de graduação avançados e pós-graduação em redes. 


Arvind Krishnamurthy 
University of Washington 
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Redes de Computadores: Uma Abordagem de Sistemas sempre foi um dos melhores recursos disponíveis para 
obter um conhecimento profundo das redes de computadores. A última edição cobre os desenvolvedores recentes 
nessa área. Começando com uma visão geral no Capítulo 1, os autores sistematicamente explicam os blocos de 
montagem básicos das redes. São apresentados os conceitos tanto do hardware quanto do software. O material 
termina com um capítulo sobre aplicações, que reúne todos os conceitos. Os tópicos avançados opcionais são 
colocados em um capítulo separado. O livro-texto também contém um conjunto de exercícios de dificuldade 
variável ao final de cada capítulo, a fim de garantir que os alunos dominem o material apresentado. 


Karkal Prabhu 
Drexel University 


Peterson e Davie oferecem uma descrição detalhada, porém clara, dos protocolos da Internet em todos os níveis. 
Os alunos encontrarão muitas ferramentas de estudo que os ajudarão a obter um conhecimento completo da 
tecnologia que está transformando nossa sociedade. O livro fica melhor a cada nova edição. 


Jean Walrand 
University of California at Berkeley 


Prefácio 


Mais uma vez, este livro, agora clássico, foi revisado para mantê-lo atualizado com nosso campo em evolução. 
Embora a Internet e seus protocolos dominem as redes de todas as partes, vemos uma evolução contínua na 
tecnologia utilizada para dar suporte à Internet, com a comutação na “camada 2” oferecendo uma funcionali- 
dade rica e ferramentas poderosas para o gerenciamento de redes. A edição anterior lidava com a comutação e 
o roteamento em dois capítulos, mas uma apresentação baseada em camadas nem sempre é a melhor maneira 
de transmitir a essência do material, pois o que chamamos de comutação e roteamento, na realidade, desempe- 
nham papéis semelhantes e complementares. Esta edição do livro analisa esses tópicos de uma forma integrada, 
que expressa suas semelhanças e diferenças funcionais. Tópicos mais avançados no roteamento foram passados 
para um segundo capítulo, que pode ser ignorado, dependendo da ênfase e do nível da turma. 

Nunca fui adepto ao ensino de redes com base em uma técnica puramente em camadas, conforme in- 
dicava o prefácio da primeira edição deste livro. Algumas questões fundamentais no uso de redes, incluindo 
segurança e desempenho, não podem ser resolvidas atribuindo-lhes uma camada — não pode haver uma 
camada de “desempenho”. Esses tipos de assuntos são críticos e cruzados, e a organização deste livro continua 
a tratar de tópicos, além de camadas. Esse tipo de organização reflete muita experiência no seu uso como 
livro-texto em sala de aula, assim como uma preferência por uma abordagem que explica os fundamentos 
e também a prática atual. 

Algumas tecnologias agora ultrapassadas não aparecem mais ou tiveram um tratamento reduzido, 
incluindo token ring (um dos meus favoritos, mas certamente seu tempo já passou) e Asynchronous Transfer 
Mode (ATM). Esta edição reconhece que precisamos prestar mais atenção ao projeto da aplicação e não apenas 
ao encaminhamento de pacotes. As redes sem fios e a mobilidade também receberam mais atenção. 

Os autores, mais uma vez, trabalharam bastante para produzir uma revisão que transmita os funda- 
mentos desse campo de uma maneira pedagogicamente eficaz. Tenho o prazer de dizer que ela está melhor 
do que nunca. 


David Clark 
Novembro de 2010 
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Prefácio à Primeira Edição 


O termo código espaguete é compreendido universalmente como um insulto. Todos os bons cientistas de 
computação adoram o deus da modularidade, pois a modularidade traz muitos benefícios, incluindo o 
todo-poderoso benefício de não ser necessário entender todas as partes de um problema ao mesmo tempo 
para poder solucioná-lo. Assim, a modularidade tem um papel importante na apresentação de ideias em um 
livro, bem como na escrita de código. Se o material de um livro for organizado de modo eficaz - modularidade —, 
então o leitor pode começar no início e realmente chegar até o fim. 

O campo dos protocolos de rede talvez seja exclusivo porque a modularidade “apropriada” nos foi 
entregue na forma de um padrão internacional: o modelo de referência de sete camadas dos protocolos 
de rede da ISO. Esse modelo, que reflete uma abordagem em camadas para a modularidade, é usado quase 
universalmente como ponto de partida para as discussões da organização dos protocolos, não importando 
se o projeto em questão está em conformidade com o modelo ou se desvia dele. 

Parece óbvio organizar um livro sobre redes em torno desse modelo em camadas. Porém, existe um risco 
ao fazer isso, pois o modelo OSI não é realmente bem-sucedido na organização dos conceitos fundamentais 
das redes. Requisitos básicos como confiabilidade, controle de fluxo ou segurança podem ser resolvidos em 
sua maioria, se não na totalidade, com as camadas OSI. Esse fato causou uma grande confusão na tentativa 
de compreender o modelo de referência. Às vezes, isso exige até mesmo uma suspensão da descrença. Na 
verdade, um livro organizado estritamente de acordo com um modelo em camadas tem alguns dos atributos 
do código espaguete. 

Isso nos leva a este livro. Peterson e Davie seguem o modelo em camadas tradicional, mas eles não 
alegam que esse modelo realmente ajude a entender os grandes problemas no uso de redes. Em vez disso, 
os autores organizam a discussão dos conceitos fundamentais de uma maneira independente das camadas. 
Assim, depois de ler o livro, os leitores entenderão o controle de fluxo, controle de congestionamento, a 
melhoria da confiabilidade, a representação dos dados e a sincronização, e entenderão separadamente as 
implicações do tratamento dessas questões em uma ou outra das camadas tradicionais. 

Este é um livro atual. Ele examina os importantes protocolos que usamos atualmente — especialmente 
os protocolos da Internet. Peterson e Davie, há muito tempo, estão envolvidos com a Internet, com muita 
experiência no assunto. Assim, este livro reflete não apenas os aspectos teóricos no projeto de protocolos, 
mas os fatores reais que importam na prática. 

O livro examina alguns dos protocolos que estão aparecendo agora, de modo que o leitor possa estar 
certo de que terá uma perspectiva atualizada. Porém, mais importante do que isso, a discussão das questões 
básicas é apresentada de uma maneira derivada da natureza fundamental do problema, e não das restrições 
do modelo de referência em camadas ou dos detalhes dos protocolos atuais. Em relação a isso, o que este 
livro apresenta é tanto atual como atemporal. 

A combinação de relevância do mundo real, exemplos atuais e explicação cuidadosa dos fundamentos 
torna este livro exclusivo. 


David D. Clark 
Massachusetts Institute of Technology 


Apresentação 


Em 1996, quando a primeira edição deste livro foi publicada, era uma novidade poder comprar mercadorias 
pela Internet, e uma empresa que anunciasse seu nome de domínio era considerada moderna. Uma família 
se conectava à Internet principalmente por meio de um modem discado. Hoje, o comércio na Internet é um 
fato da vida, e ações “.com” passaram por um ciclo inteiro de crescimento e queda. Redes sem fios estão em 
toda a parte e novos dispositivos preparados para Internet, como smartphones e tablets, aparecem no mercado 
a um ritmo incrível. Parece que a única coisa previsível sobre a Internet é a mudança constante. 

Apesar dessas mudanças, a pergunta que fizemos na primeira edição ainda é válida hoje: quais são os 
conceitos e as tecnologias básicas que fazem a Internet funcionar? A resposta é que grande parte da arquite- 
tura TCP/IP continua a funcionar exatamente como foi idealizada por seus criadores há mais de trinta anos. 
Isso não significa dizer que a arquitetura da Internet é desinteressante, muito pelo contrário. Entender os 
princípios de projeto que servem de base para uma arquitetura que não apenas sobreviveu, mas promoveu 
o tipo de crescimento e mudança que a Internet tem visto nas três últimas décadas, é exatamente o lugar 
certo para começar. Assim como nas edições anteriores, a quinta edição torna o “porquê” da arquitetura da 
Internet sua pedra fundamental. 


A quem este livro se destina 


Nossa intenção é que o livro sirva como texto para uma aula abrangente sobre redes, seja em nível de pós- 
-graduação ou de graduação em um estágio avançado. Também acreditamos que o foco do livro nos conceitos 
básicos deverá ser atraente para os profissionais do setor que estejam se reciclando para tarefas relacionadas 
a redes, além dos atuais profissionais de infraestrutura que queiram entender os “porquês” por trás dos 
protocolos com que trabalham no dia a dia e ver o quadro geral do uso de redes. 

Pela nossa experiência, tanto alunos como profissionais aprendendo sobre redes pela primeira vez 
normalmente têm a impressão de que os protocolos de rede são algum tipo de decreto vindo do alto, e que 
seu trabalho é aprender tantos ATLs (Acrônimos de Três Letras) quanto possível. Na realidade, os protocolos 
são os blocos de montagem de um sistema complexo, desenvolvido pela aplicação de princípios de projeto 
da engenharia. Além do mais, eles estão constantemente sendo refinados, estendidos e substituídos com 
base na experiência do mundo real. Com isso em mente, nosso objetivo é fazer mais do que uma análise 
dos protocolos em uso atualmente. Queremos explicar os princípios básicos do projeto de redes correto. 
Acreditamos que esse conhecimento dos princípios básicos é a melhor ferramenta para lidar com a taxa de 
mudança na área de redes. 

Reconhecemos também que existem muitas maneiras diferentes para as pessoas abordarem as redes. 
Ao contrário de quando escrevemos nossa primeira edição, a maioria das pessoas apanhará este livro já tendo 
uma experiência considerável como usuários de redes. Alguns estarão aspirando a se tornarem projetistas 
de produtos ou protocolos de rede. Outros podem estar interessados em administrar redes, enquanto um 
número cada vez maior será de desenvolvedores de aplicação atuais ou futuras para dispositivos em rede. 
Nosso foco tradicionalmente tem sido nos projetistas de produtos e protocolos futuros, e isso continua a 
ser verdade; porém, nesta edição, tentamos abordar os pontos de vista tanto dos gerentes de rede como dos 
desenvolvedores de aplicações. 


Mudanças na quinta edição 


Embora nosso foco seja os princípios básicos das redes, ilustramos esses princípios usando exemplos da 
Internet de hoje. Portanto, acrescentamos muito material para acompanhar os avanços recentes no uso de 
redes. Também retiramos, reorganizamos e mudamos o foco do material existente para refletir as mudanças 
que ocorreram durante a última década. 

Talvez a mudança mais significativa que observamos desde a escrita da primeira edição seja que quase 
todo leitor agora está acostumado com aplicações em rede, como a world wide web e o correio eletrônico 
(e-mail). Por esse motivo, aumentamos o foco nas aplicações, começando no primeiro capítulo. Usamos 
aplicações como a motivação para o estudo de redes e para derivar um conjunto de requisitos que uma rede 
útil precisa atender para dar suporte a aplicações atuais e futuras em uma escala global. Porém, retemos a 
abordagem de resolução de problemas das edições anteriores, que começa com o problema de interconectar 
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hosts e sobe pelas camadas para concluir com um exame detalhado dos aspectos da camada de aplicação. 
Acreditamos que é importante tornar os tópicos abordados no livro relevantes, começando com as aplicações 
e suas necessidades. Ao mesmo tempo, acreditamos que os aspectos da camada mais alta, como os protocolos 
das camadas de aplicação e transporte, são mais bem compreendidos depois que os problemas básicos 
da conexão de hosts e da comutação de pacotes tiverem sido explicados. Dito isso, fizemos o possível para 
apresentar o material de uma maneira mais top-down, conforme descrevemos a seguir. 

Assim como nas edições anteriores, acrescentamos ou aumentamos o tratamento de novos assuntos 
importantes e atualizamos outros tópicos. Os principais tópicos novos ou atualizados substancialmente 
nesta edição são: 


e Material atualizado sobre tecnologia sem fios (wireless), particularmente os diversos tipos de redes 
802.11 (Wi-Fi), além das tecnologias sem fios para celular, incluindo os padrões de terceira (3G) 
e quarta (4G) gerações. 

e Tratamento atualizado dos mecanismos de controle de congestionamento, particularmente para redes 
com elevado produto largura de banda-atraso e redes sem fios. 

e Material atualizado sobre Web Services, incluindo as arquiteturas SOAP e REST (Representational State 
Transfer). 

e Tratamento expandido e atualizado sobre roteamento entre domínios e o protocolo de gateway 
de borda (BGP). 

e Tratamento expandido sobre protocolos para aplicações multimídia, como Voice over IP (VoIP) 
e streaming de vídeo. 


Também diminuímos o tratamento de alguns assuntos que são menos relevantes hoje em dia. Os 
protocolos que passaram para a categoria “histórica” nesta edição incluem o Asynchronous Transfer Mode 
(ATM) e token rings. 

Uma das mudanças mais significativas nesta edição é a separação do material em seções “introdutória” 
e “avançada”. Quisemos tornar o livro mais acessível para pessoas iniciantes em tecnologias e protocolos de 
rede, sem abrir mão do material avançado exigido para as turmas de nível mais alto. O efeito mais evidente 
dessa mudança é que o Capítulo 3 agora aborda os fundamentos da comutação, roteamento e interligação 
de redes, enquanto o Capítulo 4 aborda os tópicos de roteamento mais avançados, como BGP IP versão 6 e 
multicast. De modo semelhante, os fundamentos do protocolo de transporte são abordados no Capítulo 5, 
com o material mais avançado, como algoritmos de controle de congestionamento do TCP aparecendo 
no Capítulo 6. Acreditamos que isso permitirá que os leitores iniciantes nessa área entendam os conceitos 
fundamentais importantes sem que fiquem sobrecarregados com assuntos mais complexos. 

Assim como na edição anterior, incluímos uma série de notas do tipo “onde eles estão agora?”. Essas 
rápidas discussões, atualizadas para esta edição, concentram-se no sucesso e fracasso de protocolos no mundo 
real. Às vezes, elas descrevem um protocolo que a maioria das pessoas desacreditou, mas que, na realidade, 
está obtendo um sucesso maior do que o esperado; outras vezes, elas traçam o destino de um protocolo que 
não conseguiu obter sucesso com o passar do tempo. O objetivo dessas notas é tornar o material relevante, 
mostrando como as tecnologias se saíram no mundo competitivo das redes de computadores. 


Abordagem 


Para uma área que é tão dinâmica e mutável quanto as redes de comunicações, a coisa mais importante 
que um livro-texto pode oferecer é a perspectiva — distinguir entre o que é e o que não é importante, e entre 
o que é duradouro e o que é superficial. Com base em nossa experiência durante os mais de vinte e cinco 
anos realizando pesquisas que ocasionaram novas tecnologias de rede, ensinando a alunos graduados e em 
graduação sobre as tendências mais recentes em redes e oferecendo produtos de rede avançados ao mercado, 
desenvolvemos uma perspectiva - que chamamos de abordagem de sistemas — que forma a alma deste livro. 
A abordagem de sistemas possui várias implicações: 


e Primeiros princípios. Em vez de aceitar os artefatos existentes como respostas absolutas, começamos 
com os primeiros princípios e os acompanhamos pelo processo de raciocínio que levou às redes atuais. 
Isso nos permite explicar por que as redes têm a aparência atual. Pela nossa experiência, quando você 
entende os conceitos básicos, qualquer protocolo novo que você encontre será relativamente fácil 
de entender. 

e Não em camadas. Embora o material seja organizado livremente em torno das camadas de rede 
tradicionais, começando na parte inferior e subindo pela pilha de protocolos, não adotamos uma 
abordagem rigidamente em camadas. Muitos assuntos — controle de congestionamento e segurança são 
bons exemplos — possuem implicações nas partes alta e baixa da hierarquia e, portanto, são discutidos 
fora do modelo tradicional em camadas. Da mesma forma, roteadores e switches possuem tanta coisa 





ELSEVIER 


Apresentação XV 


em comum (e normalmente são combinados como um único produto) que os discutimos no mesmo 
capítulo. Resumindo, acreditamos que as camadas são boas para se utilizar como linha geral, mas não 
tão boas para se seguir cegamente; normalmente é mais útil utilizar uma abordagem fim a fim. 
Exemplos do mundo real. Em vez de explicar como os protocolos funcionam de forma abstrata, 
utilizamos os protocolos mais importantes em uso atualmente — a maioria deles vinda da Internet TCP/ 
IP — para ilustrar como as redes funcionam na prática. Isso nos permite incluir experiências do mundo 
real na discussão. 

Software. Embora as redes de níveis mais baixos sejam construídas a partir de hardware que pode 

ser comprado de fornecedores de computador e por serviços de comunicação que podem ser alugados 
da companhia telefônica, é o software que permite que as redes ofereçam novos serviços e adaptem-se 
rapidamente a circunstâncias variáveis. É por esse motivo que enfatizamos como o software de rede 

é implementado, em vez de parar com uma descrição dos algoritmos abstratos envolvidos. Também 
incluímos segmentos de código retirados de uma pilha de protocolos funcionais, a fim de ilustrar 
como você poderia implementar certos protocolos e algoritmos. 

Foco fim a fim. As redes são construídas a partir de muitos blocos construtivos e, embora seja 
necessário abstrair os elementos não interessantes ao solucionar um problema em particular, 

é essencial entender como todas as partes se encaixam para formar uma rede funcional. Portanto, 
investimos um tempo considerável explicando o comportamento geral fim a fim das redes, e não 
apenas os componentes individuais, permitindo-nos entender como uma rede completa opera, desde 
a aplicação até o hardware. 

Desempenho. A abordagem de sistemas implica realizar estudos de desempenho experimental 

e depois usar os dados coletados tanto para analisar quantitativamente diversas opções de projeto 
quanto para orientar a otimização da implementação. Essa ênfase na análise empírica permeia o livro. 
Princípios de projeto. As redes são como outros sistemas de computação — por exemplo, sistemas 
operacionais, arquiteturas de processador, sistemas distribuídos e paralelos, e assim por diante. Eles 
são todos grandes e complexos. Para ajudar a administrar essa complexidade, os criadores de sistemas 
normalmente lançam mão de uma coleção de princípios de projeto. Destacamos esses princípios 

de projeto à medida que eles são introduzidos no livro, ilustrados, logicamente, 

com exemplos de redes de computadores. 


Pedagogia e recursos 


A quinta edição mantém os recursos pedagógicos das edições anteriores, dos quais o encorajamos a tirar 
proveito, a saber: 


Descrições do problema. No início de cada capítulo, descrevemos um problema que identifica 

o próximo conjunto de questões que serão tratadas no projeto de uma rede. Essa descrição apresenta 

e motiva as questões a serem exploradas no capítulo. 

Notas em destaque. Ao longo do texto, notas com um fundo sombreado explicam o assunto sendo 
discutido ou apresentam um tópico avançado relacionado. Em muitos casos, essas notas se relacionam 
a anedotas do mundo real sobre o uso de redes. 

Notas de “onde estão agora”. Esses novos elementos — um estilo de nota com um formato distinto — 
acompanham o sucesso e o fracasso de protocolos implementados no mundo real. 

Parágrafos em destaque. Esses parágrafos resumem um trecho importante da informação, 

que queremos que você apreenda da discussão, como um princípio de projeto de sistemas que pode 
ser amplamente aplicado. 

Protocolos reais. Embora o foco deste livro seja os conceitos básicos, em vez das especificações de protocolo 
existentes, protocolos reais são usados para ilustrar a maioria das ideias importantes. Como resultado, 

o livro pode ser usado como uma fonte de referência para muitos protocolos. Para ajudá-lo a encontrar 

as descrições dos protocolos, cada título de seção aplicável identifica entre parênteses os protocolos 
descritos naquela seção. Por exemplo, a Seção 5.2, que descreve os princípios dos protocolos fim a fim 
confiáveis, fornece uma descrição detalhada do TCP um exemplo canônico de um protocolo desse tipo. 
Discussões “O que vem depois?” Concluímos o corpo principal de cada capítulo com uma questão 
importante que está atualmente se desenrolando na comunidade de pesquisa, no mundo comercial 
ou na sociedade como um todo. Descobrimos que a discussão dessas questões prospectivas ajuda 

a tornar o assunto de redes mais relevante e interessante. 

Leitura recomendada. Essas listas altamente seletivas aparecem ao final de cada capítulo. Cada lista 
geralmente contém os artigos seminais sobre os tópicos recém-discutidos. Recomendamos fortemente 
que os leitores avançados (por exemplo, alunos de pós-graduação) estudem os artigos na lista de leitura 
para complementar o material abordado no capítulo. 
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Roteiro e uso do curso 
O livro está organizado da seguinte maneira: 


e O Capítulo 1 apresenta um conjunto das principais ideias que são usadas no restante do texto. 
Motivado por aplicações amplamente adotadas, ele discute o que existe em uma arquitetura 
de rede, fornece uma introdução a questões de implementação de protocolos e define as métricas 
de desempenho quantitativo que geralmente direcionam projetos de redes. 

e O Capítulo 2 analisa as muitas maneiras como um usuário pode se conectar a uma rede maior, 
como a Internet, apresentando assim o conceito de enlaces (links). Ele também descreve muitas 
das questões que todos os protocolos da camada de enlace precisam enfrentar, como a codificação, 

o enquadramento e a detecção de erros. As tecnologias de enlace mais importantes atualmente — 
Ethernet e Wireless — são descritas aqui. 

e O Capítulo 3 apresenta os conceitos básicos de comutação e de roteamento, começando com 
os modelos de circuito virtual e de datagramas. Explicamos as pontes e a comutação de LANSs, seguido 
por uma introdução à interligação de redes, incluindo o Internet Protocol (IP) e os protocolos 
de roteamento. O capítulo conclui discutindo uma série de técnicas baseadas em hardware e software 
para a montagem de roteadores e switches. 

e O Capítulo 4 aborda tópicos avançados de interligação de redes. Entre eles estão protocolos 
de roteamento multiárea, roteamento interdomínios e BGP IP versão 6, Multiprotocol Label Switching 
(MPLS) e multicast. 

e O Capítulo 5 sobe até o nível de transporte, descrevendo com detalhes o Transmission Control Protocol 
(TCP) da Internet e a Remote Procedure Call (RPC), usados para construir aplicações cliente-servidor. 
O Real-time Transport Protocol (RTP), que fornece suporte a aplicações multimídia, também é descrito 
aqui. 

e O Capítulo 6 discute sobre controle de congestionamento e alocação de recursos. Os problemas nesse 
capítulo envolvem o nível de enlace (Capítulo 2), o nível de rede (Capítulos 3 e 4) e o nível de transporte 
(Capítulo 5). Particularmente, esse capítulo descreve como funciona o controle de congestionamento 
no TCP e apresenta os mecanismos usados para fornecer qualidade de serviço no IP 

e O Capítulo 7 considera os dados enviados por uma rede. Isso inclui tanto os problemas de formatação 
para a apresentação quanto os de sua compressão. O XML é explicado aqui, e a seção de compressão 
inclui explicações sobre como funcionam a compressão de vídeo MPEG e a compressão de áudio MP3. 

e O Capítulo 8 discute segurança de redes, começando com uma visão geral das ferramentas 
criptográficas, os problemas de distribuição de chaves e uma discussão sobre várias técnicas 
de autenticação usando chaves públicas e privadas. O foco principal desse capítulo é a criação 
de sistemas seguros, usando exemplos que incluem Pretty Good Privacy (PGP), Secure Shell (SSH), 

e a arquitetura IP Security (IPSEC). Os firewalls também são explicados aqui. 

e O Capítulo 9 descreve um exemplo representativo das aplicações de rede e os protocolos que elas 
utilizam, incluindo aplicações tradicionais como o e-mail e a web, aplicações multimídia como 
telefonia IP e streaming de vídeo, e redes overlay, como o compartilhamento de arquivos peer-to-peer e 
as redes de distribuição de conteúdo. Os serviços de infraestrutura - o Domain Name System (DNS) 

e o gerenciamento de rede — são descritos aqui. As arquiteturas de Web Services para o desenvolvimento 
de novos protocolos de aplicação também são apresentadas aqui. 


Para um curso de graduação, provavelmente será preciso um tempo extra na aula para ajudar os alunos 
a entenderem o material introdutório no primeiro capítulo, provavelmente em detrimento de material mais 
avançado explicado nos Capítulos 4, 6, 7 e 8. O Capítulo 9, então, retorna ao assunto popular das aplicações 
de rede. Uma turma de graduação poderia, de modo aceitável, passar superficialmente pelas seções mais 
avançadas (por exemplo, as Seções 5.3, 9.3.1, 9.3.2 e 9.2.2.). 

Por outro lado, o instrutor de um curso de pós-graduação deverá explicar o primeiro capítulo em apenas 
uma ou duas aulas — com os alunos estudando o material com mais cuidado por conta própria -, liberando as- 
sim um tempo de aula adicional para explicar o Capítulo 4 e os últimos capítulos com mais profundidade. 

Para aqueles que estão usando o livro como autoestudo, acreditamos que os tópicos que selecionamos 
abordam a parte mais importante das redes de computadores, e por isso recomendamos que o livro seja lido 
sequencialmente, de capa a capa. Além disso, incluímos uma boa quantidade de referências para ajudá-lo 
a localizar material suplementar relevante às suas áreas de interesse específicas, e incluímos soluções para 
exercícios selecionados. 

O livro utiliza uma abordagem exclusiva para o assunto de controle de congestionamento, colocando 
todos os tópicos relativos ao controle de congestionamento e alocação de recursos em um único lugar — o 
Capítulo 6. Fizemos isso porque o problema de controle de congestionamento não pode ser resolvido em um 
nível apenas, e queremos que você considere as diversas opções de projeto ao mesmo tempo. (Isso é coerente 
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com nossa visão de que o uso estrito das camadas normalmente atrapalha importantes escolhas de projeto.) 
Porém, é possível realizar um tratamento mais tradicional do controle de congestionamento, estudando a 
Seção 6.2 no contexto do Capítulo 3 e a Seção 6.3 no contexto do Capítulo 5. 


Um caminho de cima para baixo 


Como a maioria dos alunos atualmente entra em uma aula de redes familiarizada com as suas aplicações em 
rede, diversas turmas usam a aplicação como seu ponto de partida. Embora abordemos as aplicações em um 
alto nível no Capítulo 1, somente no Capítulo 9 discutimos com detalhes as questões da camada de aplicação. 
Reconhecendo que alguns professores ou leitores podem querer seguir uma ordem mais de cima para baixo, 
sugerimos o seguinte método como uma forma possível de estudar o material deste livro. 


e Capítulo 1. Este capítulo descreve as aplicações e seus requisitos para preparar o terreno para o restante 
do material. 

e Capítulo 9. As seções sobre aplicações tradicionais (Seção 9.1) e aplicações multimídia (Seção 9.2) 
apresentarão aos leitores os conceitos de protocolos de rede usando os exemplos de aplicações 
com as quais eles já estão acostumados. A Seção 9.3.1 (DNS) também poderia ser estudada. 

e A Seção 7.2 poderia ser estudada em seguida, para explicar como os dados gerados por aplicações 
multimídia são codificados e compactados. 

e Capítulo 5. Os fundamentos dos protocolos de transporte podem agora ser estudados, explicando 
como os dados gerados pelos protocolos da camada de aplicação podem ser transportados pela rede 
de modo confiável. 

e Capítulo 3. Comutação, Interligação de redes e Roteamento podem ser compreendidos 
como oferecendo a infraestrutura sobre a qual os protocolos de transporte são executados. 

e Capítulo 2. Finalmente, podem ser analisadas as questões de como os dados são realmente codificados 
e transmitidos em meios físicos, tais como Ethernet e enlaces sem fio. 


Logicamente, pulamos muitas seções nessa ordem de estudo. Para um curso mais avançado ou para o 
autoestudo abrangente, tópicos como alocação de recursos (Capítulo 6), segurança (Capítulo 8) e os tópicos 
avançados no Capítulo 4 poderiam ser acrescentados no final. A segurança poderia ser abordada quase 
separadamente, mas todos estes tópicos avançados farão mais sentido após o IP e o TCP terem sido abordados 
nos Capítulos 3 e 5, respectivamente. 

Observe que os slides disponibilizados em nosso site incluem um conjunto que acompanha essa ordem 
de cima para baixo, além do conjunto que segue a ordem do livro. 


Exercícios 


Muito esforço foi empregado para melhorar os exercícios a cada nova edição. Na segunda edição, aumentamos 
bastante o número de problemas e, com base em testes em sala de aula, melhoramos muito sua qualidade. 
Na terceira edição, fizemos duas outras mudanças importantes, que mantivemos aqui: 


e Para os exercícios que acreditamos ser particularmente desafiadores ou que exigem conhecimento 
especial não fornecido no livro (por exemplo, conhecimento de probabilidades), acrescentamos 
um ícone s% para indicar o nível de dificuldade extra. 

e Em cada capítulo, acrescentamos alguns exercícios extras representativos, para os quais existem 
soluções resolvidas no final do livro. Esses exercícios, marcados com „f, oferecem alguma ajuda 
para resolver outros exercícios no livro. 


Nesta edição, acrescentamos novos exercícios para refletir o conteúdo atualizado. O conjunto atual de 
exercícios possui diversos estilos distintos: 


e Exercícios analíticos que pedem ao aluno para realizar cálculos algébricos simples para demonstrar sua 
compreensão das relações fundamentais. 

e Perguntas de projeto que pedem ao aluno para propor e avaliar protocolos para diversas circunstâncias. 

e Perguntas práticas que pedem ao aluno para escrever algumas linhas de código a fim de testar uma 
ideia ou experimentar um utilitário de rede existente. 

e Perguntas de pesquisa que pedem ao aluno para aprender mais sobre um assunto em particular. 


Além disso, conforme descrevemos com mais detalhes a seguir, tarefas de programação baseada em 
sockets, além de experimentos de simulação em laboratório, estão disponíveis on-line. 
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Material suplementar e recursos on-line 


Para auxiliar os instrutores, preparamos um manual do instrutor que contém soluções para exercícios 
selecionados. O manual está disponível com a editora. 

Materiais de suporte adicionais, incluindo slides para aulas, figuras do texto, tarefas de programação 
baseada em sockets e exemplos de exames e tarefas de programação estão disponíveis em www.elsevier. 
com.br/petersonedavie. 

E, finalmente, assim como na quarta edição, um conjunto de experimentos de laboratório complementa 
o livro. Esses experimentos, desenvolvidos pelo Professor Emad Aboelela da University of Massachusetts 
em Dartmouth, utilizam simulações para explorar o comportamento, a escalabilidade e o desempenho dos 
protocolos explicados no livro. As seções que discutem o material abordado pelos exercícios de laboratório são 
marcadas com o ícone mostrado na margem. As simulações utilizam o conjunto de ferramentas de simulação 
OPNET, que está disponível gratuitamente a qualquer um que utiliza este livro em seu curso. 
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Fundamentos 


Preciso criar um sistema ou então ser escravizado pelo de outra pessoa; não vou discutir 
nem comparar: meu negócio é criar. 
William Blake 


E E Problema: montando uma rede E 


Suponha que você queira montar uma rede de computadores, uma com o potencial para crescer até 
proporções globais e prover suporte a aplicações tão diversificadas quanto teleconferência, vídeo 
sob demanda, comércio eletrônico, computação distribuída e bibliotecas digitais. Que tecnologias 
disponíveis serviriam como blocos construtivos subjacentes e que tipos de arquitetura de software 
você projetaria para integrar esses blocos construtivos em um serviço de comunicação eficiente? 

A resposta a essa pergunta é o objetivo prioritário deste livro: descrever o material construtivo 
disponível e depois mostrar como ele pode ser usado para construir uma rede de cima a baixo. 
Antes que possamos entender como projetar uma rede de computadores, primeiro temos que 
entrar em acordo sobre o que é exatamente uma rede de computadores. Em determinada época, 
o termo rede significava um conjunto de linhas seriais usadas para conectar terminais burros 

a computadores de grande porte (mainframes). Outras redes importantes incluem a rede telefônica 
de voz e a rede de TV a cabo usada para disseminar sinais de vídeo. As principais características que 
essas redes têm em comum são que elas são especializadas em lidar com um tipo de dados 

em particular (toques de teclas, voz ou vídeo) e que elas normalmente se conectam a dispositivos 
com finalidades especiais (terminais, aparelhos de telefone e aparelhos de televisão). 

O que distingue uma rede de computadores desses outros tipos de redes? Provavelmente, 

a característica mais importante de uma rede de computadores é sua generalidade. As redes 

de computadores são construídas principalmente a partir de hardware programável de uso geral, 
e elas não são otimizadas para uma aplicação em particular, como fazer ligações telefônicas ou 
enviar sinais de televisão. Em vez disso, elas são capazes de transportar muitos tipos diferentes 

de dados, e admitem uma grande e crescente gama de aplicações. As redes de computadores de 
hoje estão cada vez mais assumindo as funções realizadas anteriormente por redes de uso 
especializado. Este capítulo examina algumas aplicações típicas das redes de computadores 

e discute os requisitos que precisam ser conhecidos por um projetista de rede que deseja dar 
suporte a tais aplicações. 

Após entendermos os requisitos, como procedemos? Felizmente, não estaremos montando 

a primeira rede. Outros, principalmente a comunidade de pesquisadores responsáveis pela 
Internet, fizeram isso antes de nós. Usaremos a riqueza de experiência gerada pela Internet 

para orientar nosso projeto. Essa experiência está incorporada em uma arquitetura de rede 

que identifica os componentes de hardware e software disponíveis e mostra como eles podem 

ser arranjados para formar um sistema de rede completo. 

Além de entender como as redes são construídas, é cada vez mais importante entender como elas 
são operadas ou administradas e como as aplicações em rede são desenvolvidas. A maioria de nós 
agora possui redes de computadores em nossas casas, escritórios e, em alguns casos, em nossos 
carros, de modo que a operação das redes não é mais um assunto apenas para alguns poucos 
especialistas. Além do mais, com a proliferação dos dispositivos programáveis e conectados à 
rede, como os smartphones, muito mais pessoas desta geração desenvolverão aplicações em rede 
do que no passado. Assim, precisamos considerar as redes de vários pontos de vista diferentes: 
montadores, operadores e desenvolvedores de aplicações. 
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Para iniciar nossa jornada no sentido de compreender como montar, operar e programar uma rede, 

este capítulo faz quatro coisas. Em primeiro lugar, ele explora os requisitos que diferentes aplicações 

e diferentes grupos de pessoas exigem da rede. Em segundo lugar, ele apresenta a ideia de uma 
arquitetura de rede, que prepara o alicerce para o restante do livro. Em terceiro lugar, ele introduz alguns 
dos elementos fundamentais na implementação de redes de computadores. Finalmente, ele identifica 
as principais métricas que são usadas para avaliar o desempenho das redes de computadores. 


1.1 Aplicações 


A maior parte das pessoas conhece a Internet por meio de suas aplicações: a World Wide Web, e-mail, 
redes sociais on-line, streaming de áudio e vídeo, mensagens instantâneas, compartilhamento de 
arquivos, para citar apenas alguns exemplos. Isso quer dizer que interagimos com a Internet como 
usuários da rede. Os usuários da Internet representam a maior classe de pessoas que interagem com a 
Internet de alguma maneira, mas existem vários outros grupos importantes. Existe o grupo de pessoas 
que criam as aplicações - um grupo que se expandiu bastante nos últimos anos, quando plataformas 
de programação poderosas e novos dispositivos, como smartphones, criaram novas oportunidades para 
desenvolver aplicações rapidamente e levá-las para um grande mercado. Depois existem aqueles que 
operam ou administram as redes — em sua maior parte, uma tarefa feita nos bastidores, mas fundamental 
e normalmente muito complexa. Com a prevalência das redes domésticas, mais e mais pessoas também 
estão se tornando, mesmo que de uma forma limitada, operadores de rede. Finalmente, existem aqueles 
que projetam e controem os dispositivos e protocolos que coletivamente compõem a Internet. Este 
último grupo é o alvo tradicional de livros sobre redes, como este, e continuará a ser nosso foco principal. 
Porém, no decorrer deste livro, também vamos considerar os pontos de vista dos desenvolvedores de 
aplicação e operadores de rede. Considerar esses pontos de vista nos permitirá entender melhor os 
diversos requisitos a que uma rede precisa atender. Os desenvolvedores de aplicação também poderão 
criar aplicações que funcionarão melhor se eles entenderem como a tecnologia subjacente funciona e 
interage com as aplicações. Assim, antes de começarmos a descobrir como montar uma rede, vejamos 
mais de perto os tipos de aplicações que as redes de hoje utilizam. 


1.1.1 Classes de aplicações 


A World Wide Web é a aplicação que transformou a Internet, de uma ferramenta um tanto obscura, 
usada principalmente por cientistas e engenheiros, no fenômeno popular que ela é hoje. A Web em si 
tornou-se uma plataforma tão poderosa que muitas pessoas a confundem com a Internet (como em 
“Interwebs”), e podemos forçar um pouco e dizer que a Web é uma única aplicação. 

Em sua forma básica, a Web apresenta uma interface intuitivamente simples. Os usuários veem 
páginas repletas de texto e objetos gráficos, eventualmente clicando em objetos que desejam descobrir 
mais a respeito, e então aparece uma nova página correspondente. A maioria das pessoas também sabe 
que, por trás, cada objeto que pode ser selecionado em uma página está ligado a um identificador para 
a próxima página ou objeto a ser visto. Esse identificador, chamado Uniform Resource Locator (URL), 
oferece um modo de identificar todos os possíveis objetos que podem ser vistos pelo seu navegador 
Web. Por exemplo, 


http://www.cs.princeton.edu/-IIp/index.html 


é o URL para uma página que fornece informações sobre um dos autores deste livro: a sequência http 
indica que o Hypertext Transfer Protocol (HTTP) deverá ser usado para baixar a página; www.cs.princeton. 
edu é o nome da máquina que serve a página; e 


Flp/index.html 


identifica de forma exclusiva a página inicial de Larry nesse site. 
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Porém, o que a maioria dos usuários da Web não sabe é que, clicando em apenas um URL desse tipo, 
mais de uma dúzia de mensagens podem ser trocadas pela Internet, e muito mais do que isso se a página 
Web for complicada, com muitos objetos embutidos. Essa troca de mensagens inclui até seis mensagens 
para traduzir o nome do servidor (www.cs.princeton.edu) para o seu endereço IP (Internet Protocol), 
128.112.136.35, três mensagens para estabelecer a conexão do Transmission Control Protocol (TCP) entre 
o seu navegador e esse servidor, quatro mensagens para o seu navegador enviar a solicitação “GET” do 
HTTP e o servidor responder com a página solicitada (e para cada lado confirmar o recebimento dessa 
mensagem) e quatro mensagens para terminar a conexão TCP Naturalmente, isso não inclui os milhões 
de mensagens trocadas pelos nós da Internet durante o dia, apenas para permitir que cada nó saiba que 
o outro existe e que está pronto para servir páginas Web, traduzir nomes em endereços e encaminhar 
mensagens para o seu destino final. 

Outra classe de aplicações conhecida na Internet é a transmissão de áudio e vídeo via “streaming” 
ou fluxo contínuo. Serviços como vídeo sob demanda e rádio pela Internet utilizam essa tecnologia. 
Embora normalmente comecemos em um site Web para iniciar uma sessão de streaming, a transmis- 
são de áudio e vídeo tem algumas diferenças importantes da busca de uma página Web simples, com 
texto e imagens. Por exemplo, você normalmente não deseja baixar um arquivo de vídeo inteiro - um 
processo que poderia levar minutos ou horas — antes de começar a ver a primeira cena. O streaming 
de áudio e vídeo proporciona uma transferência de mensagens do emissor ao receptor considerando a 
relação de tempo entre os dados, e o receptor exibe o vídeo ou toca o áudio logo depois que ele começa 
a chegar. 

Observe que a diferença entre as aplicações de streaming e a transmissão mais tradicional de uma 
página de texto ou imagens paradas é que os humanos consomem fluxos de áudio e vídeo de uma ma- 
neira contínua, e a descontinuidade — na forma de sons picotados ou vídeo com paradas — é inaceitável. 
Por outro lado, uma página de texto pode ser entregue e lida em pedaços. Essa diferença afeta o modo 
como a rede oferece suporte para essas diferentes classes de aplicações. 

Uma classe de aplicação sutilmente diferente é o áudio e vídeo em tempo real. Essas aplicações 
possuem restrições de tempo muito maiores do que as aplicações de streaming. Quando usamos uma 
aplicação de voz-sobre-IP como Skype™, ou uma aplicação de videoconferência, as interações entre 
os participantes precisam ser imediatas. Quando uma pessoa em uma ponta faz um gesto, então essa 
ação precisa ser mostrada na outra ponta o mais rapidamente possível. Quando uma pessoa tenta in- 
terromper outra, a pessoa interrompida precisa ouvir isso o mais cedo possível! e decidir se permitirá 
a interrupção ou continuará falando sem dar chance a quem interrompeu. Um excesso de atraso nesse 
tipo de ambiente torna o sistema inutilizável. Compare isso com o vídeo sob demanda, no qual, se forem 
gastos vários segundos desde o momento em que o usuário inicia o vídeo até que a primeira imagem 
seja exibida, o serviço ainda é considerado satisfatório. Além disso, aplicações interativas normalmente 
envolvem fluxos de áudio e/ou vídeo nos dois sentidos, enquanto uma aplicação de streaming prova- 
velmente envia vídeo ou áudio em apenas um sentido. 

Ferramentas de videoconferência que operam via Internet já existem desde o início da década de 
1990, mas estão sendo muito mais utilizadas nos últimos dois anos, à medida que maiores velocidades 
de rede e computadores mais poderosos se tornam cada vez mais comuns. Um exemplo desse tipo de 
sistema aparece na Figura 1.1. Assim como baixar uma página Web envolve muito mais do que os olhos 
veem, o mesmo ocorre com aplicações de vídeo. Adaptar o conteúdo de vídeo a uma rede com largura 
de banda relativamente baixa, por exemplo, ou garantir que vídeo e áudio permaneçam em sincronismo 
e cheguem a tempo para proporcionar uma boa experiência do usuário são problemas com os quais 
projetistas de redes e de protocolos precisam se preocupar. Veremos estes e muitos outros aspectos 
relacionados a aplicações multimídia mais adiante no livro. 

Embora estes sejam apenas dois exemplos, a capacidade de obter páginas da Web e participar em 
uma videoconferência demonstram a diversidade de aplicações que podem ser criadas em cima da 


!Não tanto “o mais rápido possível” — pesquisa de fatores humanos indica que 300 ms é um limite razoável para que um 
atraso de ida e volta seja tolerado em uma ligação telefônica antes que os humanos reclamem, e um atraso de 100 ms ainda 
é muito bom. 
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FIGURA 1.1 Uma aplicação multimídia incluindo videoconferência. 


Internet e sugerem a complexidade do projeto da Internet. Mais adiante no livro, iremos desenvolver 
uma taxonomia mais completa dos tipos de aplicação, para ajudar nossa discussão sobre as principais 
decisões de projeto enquanto buscamos montar, operar e usar redes que dão suporte a uma gama 
de aplicações tão diversificada. No Capítulo 9, o livro é concluído retornando a essas duas aplicações 
específicas, além de várias outras que ilustram a amplitude do que é possível na Internet atual. 

Por enquanto, essa visão rápida de algumas aplicações típicas será suficiente para permitir que 
comecemos a examinar os problemas que precisam ser enfrentados para podermos montar uma rede 
que ofereça suporte para tal diversidade de aplicações. 


1.2 Requisitos 


Estabelecemos uma meta ambiciosa para nós mesmos: entender como montar uma rede de computa- 
dores a partir do zero. Nossa abordagem para atingit essa meta será começar com os princípios e depois 
fazer os tipos de perguntas que faríamos naturalmente se estivéssemos montando uma rede real. A 
cada passo, usaremos os protocolos atuais para ilustrar diversas escolhas de projeto que estão à nossa 
disposição, mas não aceitaremos esses artefatos existentes como respostas absolutas. Em vez disso, 
faremos a pergunta (e a responderemos) por que as redes são projetadas da maneira como elas são. 
Embora seja tentador nos conformarmos simplesmente em entender o modo como isso é feito hoje, é 
importante reconhecer os conceitos básicos, pois as redes estão constantemente mudando enquanto 
a tecnologia evolui e novas aplicações são inventadas. Pela nossa experiência, quando você entende as 
ideias fundamentais, qualquer protocolo novo que você encontre será relativamente fácil de entender. 


1.2.1 Perspectivas 


Conforme observamos, um aluno de redes pode considerar vários pontos de vista. Quando escrevemos 
a primeira edição deste livro, a maior parte da população não tinha acesso algum à Internet, e aqueles 
que o tinham faziam isso no trabalho, em uma universidade ou por meio de um modem discado em casa. 
O conjunto de aplicações populares poderia ser contado nos dedos. Assim, como a maioria dos livros da 
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época, nosso livro focalizava o ponto de vista de alguém que projetaria o equipamento e os protocolos 
de rede. Continuamos a nos concentrar nesse ponto de vista, e nossa esperança é que, depois de ler 
este livro, você saiba como projetar os equipamentos de rede e os protocolos do futuro. Porém, também 
queremos abranger os pontos de vista de dois outros grupos que têm uma importância cada vez maior: 
aqueles que desenvolvem as aplicações de rede e aqueles que administram ou operam as redes. Vamos 
examinar como esses três grupos poderiam listar seus requisitos para uma rede: 


e Um programador de aplicação listaria os serviços que sua aplicação precisa — por exemplo, uma 
garantia de que cada mensagem que a aplicação envia será entregue sem erros dentro de um certo 
intervalo de tempo ou a capacidade de alternar de modo controlado entre diferentes conexões 
com a rede enquanto o usuário se movimenta. 

e Um operador de rede listaria as características de um sistema que seja fácil de administrar e 
gerenciar — por exemplo, em que as falhas podem ser facilmente isoladas, novos dispositivos 
podem ser acrescentados à rede e configurados corretamente, e no qual seja fácil contabilizar o 
uso de recursos. 

e Um projetista de rede listaria as propriedades de um projeto econômico — por exemplo, que os 
recursos da rede sejam utilizados de modo eficaz e alocados de forma justa a diferentes usuários. 
As questões de desempenho provavelmente também seriam importantes. 


Esta seção tenta extrair esses diferentes pontos de vista em uma introdução de alto nível às principais 
considerações que impulsionam o projeto da rede e, ao fazer isso, identifica os desafios abordados no 
decorrer do restante deste livro. 


1.2.2 Conectividade escalável 


Começando pelo óbvio, uma rede precisa fornecer conectividade entre um conjunto de computadores. 
Às vezes, é suficiente montar uma rede limitada, que conecta apenas algumas máquinas selecionadas. 
De fato, por questões de privacidade e de segurança, muitas redes privadas (corporativas) possuem 
o objetivo explícito de limitar o conjunto de máquinas que estão conectadas. Por outro lado, outras 
redes (das quais a Internet é o principal exemplo) são projetadas para crescer de um modo que elas 
apresentem o potencial de conectar todos os computadores do mundo inteiro. Diz-se que um sistema 
é escalável quando ele é projetado para dar suporte ao crescimento até um tamanho arbitrariamente 
grande. Usando a Internet como um modelo, este livro trata do desafio da escalabilidade. 


Enlaces, nós e nuvens 

Para entender melhor os requisitos de conectividade, precisamos ver mais de perto como os compu- 
tadores estão conectados em uma rede. A conectividade ocorre em muitos níveis diferentes. No nível 
mais baixo, uma rede pode consistir em dois ou mais computadores conectados diretamente por algum 
meio físico, como um cabo coaxial ou uma fibra óptica. Chamamos esse meio físico de enlace (ou link), 
e frequentemente nos referimos aos computadores que ele conecta como nós. (Às vezes, um nó é um 
equipamento de hardware mais especializado, em vez de um computador, mas vamos deixar essa 
distinção de lado para os propósitos desta discussão.) Conforme ilustramos na Figura 1.2, os enlaces 
físicos às vezes são limitados a um par de nós (esse enlace é considerado ponto a ponto), enquanto em 
outros casos mais de dois nós podem compartilhar um único enlace físico (esse enlace é considerado 
de acesso múltiplo). Os enlaces sem fio, como aqueles fornecidos por redes de celulares e redes Wi-Fi, 
são uma classe cada vez mais importante de enlaces de acesso múltiplo. Frequentemente os enlaces de 
acesso múltiplo são limitados em tamanho, em termos tanto da distância geográfica que eles podem 
alcançar quanto do número de nós que eles podem conectar. 

Se as redes de computadores fossem limitadas a situações em que todos os nós são conectados 
diretamente uns aos outros por um meio físico compartilhado, então ou as redes seriam muito limi- 
tadas no número de computadores que elas poderiam conectar, ou o número de fios saindo de cada 
nó rapidamente se tornaria incontrolável e sua ligação muito cara. Felizmente, a conectividade entre 
dois nós não necessariamente significa uma conexão física direta entre eles — a conectividade indireta 
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FIGURA 1.2 Enlaces diretos: (a) ponto a ponto; (b) acesso múltiplo. 


pode ser obtida por meio da cooperação de um conjunto de nós. Considere os dois exemplos a seguir 
de como uma coleção de computadores pode ser conectada indiretamente. 

A Figura 1.3 mostra um conjunto de nós, cada um conectado a um ou mais enlaces ponto a ponto. 
Aqueles nós que estão conectados a pelo menos dois enlaces executam um software que encaminha 
os dados recebidos em um enlace para outro. Se organizados de uma maneira sistemática, esses nós de 
encaminhamento formam uma rede comutada. Existem vários tipos de redes comutadas, das quais as 
duas mais comuns são as redes de comutação de circuitos e de comutação de pacotes. A primeira é em- 
pregada principalmente pelo sistema telefônico, enquanto a segunda é usada para a esmagadora maioria 
das redes de computadores, e será o foco deste livro. (Porém, a comutação de circuitos está retornando 
no âmbito das redes ópticas, que se mostram importantes dado que a demanda por capacidade de 
rede aumenta constantemente.) O recurso importante das redes de comutação de pacotes é que os nós 
nesse tipo de rede enviam blocos discretos de dados uns para os outros. Pense nesses blocos de dados 
como se correspondessem a algum pedaço dos dados da aplicação, como um arquivo, uma mensagem 





FIGURA 1.3 Rede comutada. 
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de e-mail ou uma imagem. Chamamos cada um desses blocos de dados de pacote ou mensagem, e por 
enquanto usamos esses termos para indicar a mesma coisa; na Seção 1.2.3, veremos o motivo pelo qual 
eles nem sempre têm o mesmo significado. 

As redes de comutação de pacotes normalmente utilizam uma estratégia chamada armazenar e 
encaminhar (store-and-forward). Como o nome indica, cada nó em uma rede do tipo armazenar 
e encaminhar primeiro recebe um pacote completo por algum enlace, armazena o pacote em sua 
memória interna e depois encaminha o pacote completo ao próximo nó. Por outro lado, uma rede 
de comutação de circuitos primeiro estabelece um circuito dedicado composto por uma sequência de 
enlaces e depois permite que o nó de origem envie um fluxo de bits por esse circuito até um nó 
de destino. O motivo principal para o uso da comutação de pacotes em vez da comutação de circuitos 
em uma rede de computadores é a eficiência, discutida na próxima subseção. 

A nuvem na Figura 1.3 distingue entre os nós em seu interior, que implementam a rede (eles nor- 
malmente são chamados de comutadores ou switches, e sua função principal é armazenar e encami- 
nhar pacotes) e os nós no exterior da nuvem, que utilizam a rede (eles quase sempre são chamados de 
estações ou hosts, e dão suporte aos usuários e executam programas de aplicação). Observe também que 
a nuvem na Figura 1.3 é um dos ícones mais importantes da rede de computadores. Em geral, usamos 
uma nuvem para indicar qualquer tipo de rede, seja ela um único enlace ponto a ponto, um enlace de 
acesso múltiplo ou uma rede comutada. Assim, sempre que você encontrar uma nuvem usada em uma 
figura, poderá pensar nela como uma abstração para qualquer uma das tecnologias de interligação de 
redes abordadas neste livro.” 

Uma segunda maneira de conectar indiretamente um conjunto de computadores é mostrada na 
Figura 1.4. Nessa situação, diversas redes (nuvens) independentes são interconectadas para formar uma 
interligação de redes, ou internet, para abreviar. Adotamos a convenção da Internet de nos referirmos a 
uma interligação de redes genérica como uma internet com i minúsculo, e à Internet baseada em TCP/ 
IP atualmente em operação como a Internet com I maiúsculo. Um nó que está conectado a duas ou mais 
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FIGURA 1.4 Interconexão de redes. 


2É interessante notar que o uso de nuvens dessa maneira é anterior ao termo computação em nuvem por, pelo menos, duas 
décadas, mas existe uma conexão entre esses dois usos, conforme discutiremos mais adiante. 
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redes normalmente é chamado de roteador ou gateway, e desempenha o mesmo papel de um switch — 
ele encaminha mensagens de uma rede para outra. Observe que uma internet em si pode ser vista como 
outro tipo de rede, o que significa que uma internet pode ser construída a partir de uma interconexão 
de internets. Assim, podemos montar recursivamente redes cada vez maiores, interconectando nuvens 
para formar nuvens maiores. Pode-se argumentar logicamente que essa ideia de interconectar redes 
bastante diferentes foi a inovação fundamental da Internet e que o crescimento bem-sucedido da In- 
ternet para um porte global e bilhões de nós foi o resultado de algumas decisões de projeto muito boas, 
feitas pelos primeiros arquitetos da Internet — discutiremos sobre isso mais adiante. 

Só porque um conjunto de hosts está conectado direta ou indiretamente uns aos outros não 
significa que obtivemos uma conectividade host a host com sucesso. O requisito final é que cada nó 
seja capaz de dizer com qual dos outros nós na rede ele deseja se comunicar. Isso é feito atribuindo-se 
um endereço a cada nó. Um endereço é uma sequência de bytes que identifica um nó; ou seja, a rede 
pode usar o endereço de um nó para distingui-lo dos outros nós conectados à rede. Quando um nó de 
origem deseja que a rede entregue uma mensagem a um certo nó de destino, ele especifica o endereço 
desse nó de destino. Se os nós emissor e receptor não estiverem conectados diretamente, então os 
switches e roteadores da rede utilizam esse endereço para decidir como encaminhar a mensagem para 
o seu destino. O processo de determinar sistematicamente como encaminhar mensagens para o nó de 
destino com base no seu endereço é chamado de roteamento. 

Esta breve introdução ao endereçamento e roteamento pressupõe que o nó de origem deseja enviar 
uma mensagem a um único nó de destino (unicast). Embora esse seja o cenário mais comum, também é 
possível que o nó de origem queira enviar uma mensagem a todos os nós na rede (broadcast). Ou então, 
um nó de origem poderia querer enviar uma mensagem a um subconjunto dos outros nós, mas não 
a todos eles, uma situação chamada de multicast. Assim, além dos endereços específicos de nó, outro 
requisito de uma rede é que ela tenha suporte a endereços de multicast e broadcast. 


A ideia principal que deve ficar desta discussão é que podemos definir uma rede recursivamente como 
consistindo em dois ou mais nós conectados por um enlace físico, ou como duas ou mais redes conectadas 
por um nó. Em outras palavras, uma rede pode ser construída a partir de um aninhamento de redes onde, 


no nível mais baixo, a rede é implementada por algum meio físico. Entre os principais desafios em fornecer 
conectividade na rede estão a definição de um endereço para cada nó que pode ser alcançado na rede 
(incluindo o suporte a broadcast e multicast) e o uso desses endereços para encaminhar mensagens para o(s) 
nó(s) de destino apropriado(s). 





1.2.3 Compartilhamento de recursos de forma econômica 


Como já dissemos, este livro aborda as redes de comutação de pacotes. Esta seção explica o principal 
requisito das redes de computadores - eficiência —, o que nos leva à comutação de pacotes como a 
estratégia escolhida. 

Dada uma coleção de nós conectados indiretamente por um aninhamento de redes, é possível que 
qualquer par de hosts envie mensagens um para o outro por meio de uma sequência de enlaces e nós. 
Naturalmente, queremos fazer mais do que admitir apenas um par de hosts se comunicando - queremos 
prover a todos os pares de hosts a capacidade de trocar mensagens. A questão, portanto, é como todos os 
hosts que querem se comunicar compartilham a rede, especialmente se quiserem utilizá-la ao mesmo 
tempo? E, como se esse problema não fosse difícil o suficiente, como vários hosts compartilham o 
mesmo enlace quando todos eles querem usá-lo ao mesmo tempo? 

Para entender como os hosts compartilham uma rede, precisamos introduzir um conceito funda- 
mental, a multiplexação, que significa que um recurso do sistema é compartilhado entre vários usuários. 
De forma intuitiva, a multiplexação pode ser explicada por meio de uma analogia com um sistema de 
computação de tempo compartilhado, em que um único processador físico é compartilhado (multi- 
plexado) entre várias tarefas, cada uma acreditando ter seu próprio processador particular. De modo 
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FIGURA 1.5 Multiplexando diversos fluxos lógicos por um único enlace físico. 


semelhante, os dados sendo enviados por vários usuários podem ser multiplexados pelos enlaces físicos 
que compõem uma rede. 

Para ver como isso poderia funcionar, considere uma rede simples, ilustrada na Figura 1.5, em que os 
três hosts no lado esquerdo da rede (emissores S1-S2) estão enviando dados para os três hosts no lado 
direito (receptores R1-R3), compartilhando uma rede comutada que contém apenas um enlace físico. 
(Para simplificar, consideramos que o host S1 está enviando dados para o host R1, e assim por diante.) 
Nessa situação, três fluxos de dados — correspondentes aos três pares de hosts — são multiplexados em 
um único enlace físico pelo switch 1 e depois demultiplexados novamente em fluxos separados pelo 
switch 2. Observe que estamos sendo intencionalmente vagos a respeito do significado exato de um 
“ftuxo de dados”. Para os propósitos desta discussão, suponha que cada host no lado esquerdo tenha 
uma grande quantidade de dados que ele queira enviar para seu correspondente no lado direito. 

Existem diversos métodos diferentes para multiplexar vários fluxos em um único enlace físico. Um 
método comum é a multiplexação síncrona por divisão de tempo (STDM - Synchronous Time-Division 
Multiplexing). A ideia da STDM é dividir o tempo em porções de mesmo tamanho e, em uma forma 
de rodízio (processo conhecido como escalonamento round-robin), dar a cada fluxo uma chance de 
enviar seus dados pelo enlace físico. Em outras palavras, durante a porção de tempo 1, os dados de S1 
para R1 são transmitidos; durante a porção de tempo 2, os dados de S2 para R2 são transmitidos; na 
porção 3, S3 envia dados para R3. Nesse ponto, o primeiro fluxo (S1 para R1) tem a vez novamente, e o 
processo se repete. Outro método é a multiplexação por divisão de frequência (FDM — Frequency-Division 
Multiplexing). A ideia da FDM é transmitir cada fluxo pelo enlace físico em uma frequência diferente, 
da mesma forma como os sinais para diferentes estações de TV são transmitidos em uma frequência 
diferente pelas ondas do ar ou por um enlace coaxial físico na TV a cabo. 

Embora simples de entender, tanto a STDM como a FDM são limitadas de duas maneiras. Primeiro, 
se um dos fluxos (pares de hosts) não tiver dados para enviar, sua fatia do enlace físico — ou seja, sua 
porção de tempo ou sua frequência — permanece ociosa, mesmo que um dos outros fluxos tenha dados 
para transmitir. Por exemplo, S3 teria que esperar sua vez depois de S1 e S2 no parágrafo anterior, mesmo 
que S1 e S2 não tivessem nada para enviar. Para a comunicação por computador, a quantidade de tempo 
que um enlace fica ocioso pode ser muito grande — por exemplo, considere o tempo que você gasta lendo 
uma página Web (deixando o enlace ocioso) em comparação com o tempo que você gasta buscando a 
página. Em segundo lugar, STDM e FDM são limitadas a situações em que o número máximo de fluxos 
é fixo e conhecido previamente. Não é prático redimensionar a porção de tempo ou acrescentar porções 
adicionais no caso da STDM ou acrescentar novas frequências no caso da FDM. 

A forma de multiplexação que resolve esses problemas, e que mais utilizamos neste livro, é chamada 
de multiplexação estatística. Embora o nome não seja tão útil para entender o conceito, a multiplexação 
estatística é realmente muito simples, com duas ideias-chave. Primeiro, ela é como a STDM no sentido 
de que o enlace físico é compartilhado no tempo — primeiro os dados de um fluxo são transmitidos pelo 


10 REDES DE COMPUTADORES ELSEVIER 


enlace físico, depois os dados de outro fluxo são transmitidos, e assim por diante. Porém, diferentemente 
da STDM, os dados de cada fluxo são transmitidos sob demanda, e não durante uma porção de tempo 
predeterminada. Assim, se apenas um fluxo tiver dados para enviar, ele passa a transmitir esses dados 
sem esperar a chegada de sua porção e, desse modo, sem ter que observar as porções atribuídas aos 
outros fluxos passarem sem serem utilizadas. É o fato de evitar esse tempo ocioso que provê à comutação 
de pacotes sua eficiência. 

Entretanto, conforme definimos até aqui, a multiplexação estatística não possui um mecanismo para 
garantir que todos os fluxos, por fim, tenham uma chance de transmitir seus dados pelo enlace físico. 
Ou seja, quando um fluxo começa a enviar dados, precisamos de alguma forma limitar a transmissão, 
para que os outros fluxos tenham sua vez. Para levar em consideração essa necessidade, a multiplexação 
estatística define um limite superior para o tamanho do bloco de dados que cada fluxo tem permissão 
para transmitir em determinado momento. Esse bloco de dados de tamanho limitado normalmente é 
conhecido como um pacote, para distingui-lo da mensagem arbitrariamente grande que um aplicativo 
poderia querer transmitir. Como uma rede de comutação de pacotes limita o tamanho máximo dos 
pacotes, um host pode não ser capaz de enviar uma mensagem completa em apenas um pacote. A 
origem pode ter que fragmentar a mensagem em vários pacotes, com o receptor remontando os pacotes 
novamente para formar a mensagem original. 

Em outras palavras, cada fluxo envia uma sequência de pacotes pelo enlace físico, com uma decisão 
sendo tomada com base em cada pacote, a fim de decidir qual fluxo terá um pacote enviado em seguida. 
Observe que, se apenas um fluxo tiver dados para enviar, então ele pode enviar uma sequência de 
pacotes sucessivos; porém, se mais de um dos fluxos tiver dados para enviar, então seus pacotes são 
intercalados no enlace. A Figura 1.6 representa um switch multiplexando pacotes de várias origens para 
um único enlace compartilhado. 

A decisão sobre qual pacote enviar em seguida em um enlace compartilhado pode ser feita de 
várias maneiras diferentes. Por exemplo, em uma rede que consiste em switches interconectados por 
enlaces como aquele da Figura 1.5, a decisão seria feita pelo switch que transmite pacotes para o enlace 
compartilhado. (Como veremos mais adiante, nem todas as redes de comutação de pacotes realmente 
envolve switches, e elas podem usar outros mecanismos para determinar quem terá o pacote enviado 
pelo enlace em seguida.) Cada switch em uma rede de comutação de pacotes toma essa decisão de modo 
independente, com base em cada pacote. Uma das questões enfrentadas por um projetista de redes 
é como tomar essa decisão de forma justa. Por exemplo, um switch poderia ser projetado para servir 
pacotes com base na estratégia “primeiro a entrar, primeiro a sair” (FIFO — First-In, First-Out). Outra 
forma seria transmitir os pacotes de cada um dos diferentes fluxos que estejam atualmente enviando 
dados pelo switch em uma forma de rodízio. Isso poderia ser feito para garantir que certos fluxos recebam 
uma fatia em particular da largura de banda do enlace ou que eles nunca tenham seus pacotes adiados 
no switch por mais do que certo intervalo de tempo. Uma rede que tenta alocar largura de banda para 
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FIGURA 1.6 Um switch multiplexando pacotes 
ii de várias origens para um enlace compartilhado. 
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fluxos específicos é também conhecida como uma rede que suporta qualidade de serviço (QoS — Quality 
of Service), um assunto ao qual retornaremos no Capítulo 6. 

Além disso, observe na Figura 1.6 que, como o switch precisa multiplexar três fluxos de pacotes de 
entrada para um enlace de saída, é possível que o switch receba pacotes mais rápido do que o enlace 
compartilhado pode acomodar. Nesse caso, o switch é forçado a manter esses pacotes em uma unidade 
de armazenamento temporário (buffer) em sua memória. Se um switch receber pacotes mais rapida- 
mente do que ele pode enviá-los por um longo período de tempo, então o switch por fim ficará sem 
espaço em seu buffer, e alguns pacotes terão que ser descartados. Quando um switch está operando 
nesse estado, diz-se que ele está congestionado. 


A conclusão é que a multiplexação estatística define um modo econômico para vários usuários (por exemplo, 
fluxos de dados host a host) compartilharem recursos da rede (enlaces e nós) de uma maneira refinada. Ela 
define o pacote como a granularidade com o qual os enlaces da rede são alocados para diferentes fluxos, 
cada switch é capaz de escalonar o uso dos diferentes enlaces ao qual está conectado com base em cada 
pacote. A alocação justa da capacidade do enlace para diferentes fluxos e o tratamento do congestionamento 
quando ele ocorre são os principais desafios da multiplexação estatística. 


LANs, LANs, MANs e WANs 


Uma maneira de classificar as redes é com base no seu tamanho. Dois exemplos bem conhecidos são as 
redes locais (LANs) e as redes remotas (WANs); a primeira normalmente se estende por menos do que 
1km, enquanto a segunda pode alcançar o mundo inteiro. Outras redes são classificadas como redes 
metropolitanas (MANSs), que frequentemente se estendem por dezenas de quilômetros. O motivo para tais 
classificações serem interessantes é que o tamanho de uma rede normalmente tem implicações sobre a 
tecnologia básica que pode ser usada, com um fator chave sendo a quantidade de tempo gasto para os dados 
se propagarem de uma extremidade da rede até a outra; discutiremos essa questão com mais detalhes em 
capítulos mais adiante. 

Uma nota histórica interessante é que o termo rede remota não foi aplicado às primeiras WANs porque 
não havia outro tipo de rede da qual diferenciá-las. Quando os computadores eram incrivelmente raros 
e caros, não havia sentido pensar em como conectar todos os computadores em uma rede local — havia 
apenas um computador nessa área. Somente quando os computadores começaram a se proliferar é que as 
LANS se tornaram necessárias, e o termo “WAN” foi então introduzido para descrever as redes maiores, que 
interconectavam computadores geograficamente distantes. 

Outro tipo de rede que precisamos entender são as SANs (atualmente significando redes de área de 
armazenamento — Storage Area Networks —, mas inicialmente conhecidas também como redes de área de 
sistema — System Area Networks). As SANs , em geral, estão confinadas a uma única sala e conectam os 
diversos componentes de um grande sistema de computação. Por exemplo, Fibre Channel é uma tecnologia 
comum para uma SAN, usada para conectar sistemas de computação de alto desempenho a servidores de 
armazenamento e salas-cofre. Embora este livro não descreva essas redes com detalhes, elas precisam ser 
conhecidas, pois frequentemente estão na vanguarda em termos de desempenho, e porque é cada vez mais 
comum conectar tais redes para formar LANs e WANS. 





1.2.4 Suporte para serviços comuns 


A seção anterior esboçou os desafios envolvidos no fornecimento de conectividade de forma econômica 
entre um grupo de hosts, mas é extremamente simplista enxergar uma rede de computadores como algo 
simplesmente entregando pacotes entre uma coleção de computadores. É mais preciso pensar em uma 
rede como algo fornecendo meios para a comunicação entre um conjunto de processos de aplicação 
que estão distribuídos por esses computadores. Em outras palavras, o próximo requisito de uma rede 
de computadores é que os aplicativos sendo executados nos hosts conectados à rede devem ser capazes 
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de se comunicar de uma maneira que faça sentido. Do ponto de vista do desenvolvedor da aplicação, 
a rede precisa tornar sua vida mais fácil. 

Quando dois aplicativos precisam se comunicar um com o outro, muitas coisas complicadas devem 
acontecer além do simples envio de uma mensagem de um host para outro. Para os projetistas de 
aplicações, uma opção seria montar toda essa funcionalidade complicada em cada aplicativo. Porém, 
como muitas aplicações precisam de serviços comuns, é muito mais lógico implementar esses serviços 
comuns uma única vez e depois permitir que o projetista da aplicação construa sua aplicação usando 
esses serviços. O desafio para um projetista de redes é identificar o conjunto certo de serviços comuns. 
O objetivo é esconder da aplicação a complexidade da rede sem restringir demasiadamente o projetista 
da aplicação. 

Intuitivamente, vemos a rede como algo oferecendo canais lógicos sobre os quais os processos no 
nível da aplicação podem se comunicar uns com os outros; cada canal fornece o conjunto de serviços 
exigidos por essa aplicação. Em outras palavras, assim como usamos uma nuvem para representar de 
forma abstrata a conectividade entre um conjunto de computadores, agora pensamos em um canal como 
algo conectando um processo a outro. A Figura 1.7 mostra um par de processos no nível da aplicação, 
comunicando-se por um canal lógico que, por sua vez, é implementado em cima de uma nuvem que 
conecta um conjunto de hosts. Podemos pensar no canal como sendo um tubo que conecta duas 
aplicações, de modo que uma aplicação emissora pode colocar dados em uma extremidade e esperar 
que os dados sejam entregues pela rede à aplicação na outra extremidade do tubo. 

O desafio é reconhecer qual funcionalidade os canais devem oferecer para os aplicativos. Por exemplo, 
a aplicação exige uma garantia de que as mensagens enviadas pelo canal serão entregues, ou é aceitável 
que algumas mensagens deixem de chegar? É necessário que as mensagens cheguem ao processo de 
destino na mesma ordem em que foram enviadas, ou o destinatário não se importa com a ordem em 
que as mensagens chegam? A rede precisa garantir que nenhum terceiro possa bisbilhotar o canal, ou 
a privacidade não é uma preocupação? Em geral, uma rede oferece diversos tipos de canais diferentes, 
com cada aplicação selecionando o tipo que melhor atende suas necessidades. O restante desta seção 
ilustra o raciocínio envolvido na definição de canais úteis. 


Identificando padrões de comunicação comuns 

O projeto de canais abstratos envolve primeiro entender as necessidades de comunicação de um con- 
junto representativo de aplicações, depois extrair seus requisitos de comunicação comuns e finalmente 
incorporar a funcionalidade que atende a esses requisitos na rede. 


Host | 


Host 
um Aplicação | 


Host 


Aplicação 


Host Host 


FIGURA 1.7 Processos se comunicando por um canal abstrato. 
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Uma das aplicações mais antigas aceitas em qualquer rede é um programa de acesso a arquivos 
como o File Transfer Protocol (FTP) ou o Network File System (NFS). Embora muitos detalhes variem — 
por exemplo, se arquivos inteiros são transferidos pela rede ou apenas blocos isolados do arquivo 
são lidos/gravados em determinado momento -, o componente de comunicação do acesso remoto 
é caracterizado por um par de processos, um que solicita que um arquivo seja lido ou gravado e um 
segundo processo que cumpre essa solicitação. O processo que solicita acesso ao arquivo é chamado 
de cliente, e o processo que permite o acesso ao arquivo é chamado de servidor. 

A leitura de um arquivo envolve o envio pelo cliente de uma pequena mensagem de solicitação a 
um servidor, com este respondendo com uma mensagem grande, que contém os dados no arquivo. 
A gravação funciona no modo oposto - o cliente envia uma mensagem grande, contendo os dados a 
serem gravados no servidor, e este responde com uma mensagem pequena, confirmando que ocorreu 
a gravação em disco. 

Uma biblioteca digital é uma aplicação mais sofisticada do que a transferência de arquivos, mas exige 
serviços de comunicação semelhantes. Por exemplo, a Association for Computing Machinery (ACM) 
opera uma grande biblioteca digital de literatura sobre ciência da computação em 


http://portal.acm.org/dl.cfm 


Essa biblioteca tem uma grande variedade de recursos de busca e navegação, para ajudar os usuários 
a encontrarem os artigos que desejam, mas, em última análise, grande parte do que ela faz é responder 
às solicitações de arquivos do usuário, como cópias eletrônicas de artigos de periódicos, de modo 
semelhante a um servidor FTP 

Usando acesso a arquivos, uma biblioteca digital e as duas aplicações de vídeo descritas na in- 
trodução (videoconferência e vídeo sob demanda) como um exemplo representativo, poderíamos 
oferecer os dois tipos de canais a seguir: canais de solicitação/resposta e canais de fluxo de mensa- 
gens. O canal de solicitação/resposta seria usado pelas aplicações de transferência de arquivos e 
biblioteca digital. Ele garantiria que cada mensagem enviada por um lado seja recebida pelo outro 
lado e que somente uma cópia de cada mensagem seja entregue. O canal de solicitação/resposta 
também poderia proteger a privacidade e a integridade dos dados que fluem por ele, de modo que 
partes não autorizadas não possam ler ou modificar os dados sendo trocados entre os processos 
cliente e servidor. 

O canal de fluxo de mensagens poderia ser usado pelas aplicações de vídeo sob demanda e video- 
conferência, desde que seja parametrizado para dar suporte a tráfego unidirecional e bidirecional, além 
de dar suporte a diferentes propriedades de atraso. O canal de fluxo de mensagens pode não precisar 
garantir que todas as mensagens sejam entregues, pois uma aplicação de vídeo pode operar de modo 
adequado mesmo que alguns quadros de vídeo não sejam recebidos. Porém, ele precisaria garantir que 
as mensagens entregues cheguem na mesma ordem em que foram enviadas, para evitar a exibição de 
quadros fora da sequência. Assim como o canal de solicitação /resposta, o canal de fluxo de mensagens 
poderia garantir a privacidade e a integridade dos dados de vídeo. Finalmente, o canal de fluxo de 
mensagens poderia precisar dar suporte ao multicast, de modo que várias partes possam participar da 
teleconferência ou assistir ao vídeo. 

Embora seja comum que um projetista de rede lute para criar o menor número de tipos de canal 
abstratos que possam atender ao maior número de aplicações, existe um perigo na tentativa de se 
ficar com muito poucas abstrações de canal. Em termos simples, se você tem um martelo, então tudo 
se parece com um prego. Por exemplo, se tudo o que você tem são canais de fluxo de mensagens e 
de solicitação/resposta, então é tentador usá-los para a próxima aplicação que apareça, mesmo que 
nenhum deles ofereça exatamente as características exigidas pela aplicação. Assim, os projetistas 
de rede provavelmente continuarão inventando novos tipos de canais — e acrescentando opções 
aos canais existentes — enquanto os programadores de aplicação continuarem inventando novas 
aplicações. 

Observe também que, independentemente de qual funcionalidade um determinado canal fornece, 
existe a questão de onde essa funcionalidade está implementada. Em muitos casos, é mais fácil visualizar 
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a conectividade host a host da rede subjacente como simplesmente fornecendo um canal de bits, com 
qualquer semântica de comunicação de alto nível fornecida pelos hosts nas extremidades. A vantagem 
dessa abordagem é que ela permite que os switches no meio da rede sejam tão simples quanto possível — 
eles simplesmente encaminham pacotes —, mas exige que os hosts finais assumam grande parte da 
tarefa de dar suporte a canais processo a processo semanticamente ricos. A alternativa é empurrar a 
funcionalidade adicional para os switches, permitindo, assim, que os hosts finais sejam dispositivos 
“burros” (por exemplo, aparelhos de telefone). Veremos essa questão de como diversos serviços de 
rede são particionados entre os switches de pacotes e os hosts (dispositivos) finais como uma questão 
recorrente no projeto de redes. 


Confiabilidade 

Conforme sugerimos pelos exemplos considerados, a transmissão confiável de mensagens é uma 
das funções mais importantes que uma rede pode oferecer. Porém, é difícil determinar como 
oferecer essa confiabilidade sem primeiro entender como as redes podem falhar. A primeira coisa 
a reconhecer é que as redes de computadores não existem em um mundo perfeito. As máquinas 
falham e depois são reinicializadas, fibras são cortadas, interferências elétricas corrompem bits 
nos dados sendo transmitidos, switches ficam sem espaço em buffer e, se esses tipos de problemas 
não fossem motivo de preocupação suficiente, o software que gerencia o hardware pode conter 
bugs e, às vezes, encaminha pacotes para o nada. Assim, um requisito importante de uma rede é 
recuperar-se de certos tipos de falhas, de modo que os aplicativos não tenham que tratá-los ou 
sequer saber de sua existência. 

Existem três classes gerais de falhas com as quais os projetistas de rede precisam se preocupar. 
Primeiro, à medida que um pacote é transmitido por um enlace físico, erros de bit podem ser in- 
troduzidos nos dados; ou seja, um 1 é transformado em um 0 e vice-versa. Às vezes, bits isolados são 
adulterados, mas geralmente ocorre um erro em rajada - vários bits consecutivos são adulterados. Os 
erros de bit normalmente ocorrem porque forças externas, como relâmpagos, picos de tensão e fornos 
de micro-ondas, interferem com a transmissão de dados. A boa notícia é que esses erros de bit são 
muito raros, afetando na média apenas um a cada 10º a 10” bits em um cabo de cobre comum, e um 
a cada 10!2 a 10!4 bits em uma fibra óptica típica. Conforme veremos, existem técnicas que detectam 
esses erros de bit com alta probabilidade. Uma vez detectados, às vezes é possível corrigir tais erros — se 
soubermos qual ou quais bits estão corrompidos, podemos simplesmente invertê-los — enquanto em 
outros casos o dano é tão grande que é preciso descartar o pacote inteiro. Nesse caso, pode-se esperar 
que o transmissor retransmita o pacote. 

A segunda classe de falha está no nível do pacote, em vez do bit; ou seja, um pacote completo é 
perdido pela rede. Um motivo para isso acontecer é que o pacote contém um erro de bit que não pode 
ser corrigido e, portanto, precisa ser descartado. Porém, um motivo mais provável é que um dos nós 
que precisa tratar o pacote — por exemplo, um switch que o está encaminhando de um enlace para 
outro — está tão sobrecarregado que não possui espaço para armazenar o pacote e, portanto, é forçado 
a descartá-lo. Esse é o problema de congestionamento mencionado na Seção 1.2.3. Mais raramente, o 
software sendo executado em um dos nós que trata o pacote comete um erro. Por exemplo, ele poderia 
encaminhar um pacote indevidamente pelo enlace errado, de modo que o pacote nunca encontra seu 
caminho até o destino final. Conforme veremos, uma das principais dificuldades no tratamento de 
pacotes perdidos é distinguir entre um pacote que está realmente perdido e um que simplesmente está 
atrasado para chegar ao destino. 

A terceira classe de falha é no nível de nó e enlace; ou seja, um enlace físico está cortado ou o com- 
putador ao qual está conectado falha. Isso pode ser causado por um software com defeito, uma falta de 
energia ou um operador negligente. Falhas devido a um erro de configuração de um dispositivo da rede 
também são comuns. Embora qualquer uma dessas falhas possa por fim ser corrigida, elas podem ter 
um efeito dramático sobre a rede por um longo período de tempo. Porém, elas não precisam desativar a 
rede totalmente. Por exemplo, em uma rede de comutação de pacotes, às vezes é possível contornar um 
nó ou enlace com falha. Uma das dificuldades no tratamento dessa terceira classe de falha é distinguir 
entre um computador que falhou e um que está simplesmente lento ou, no caso de um enlace, entre um 
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que foi cortado e um que está operando estranhamente e, portanto, introduz uma grande quantidade 
de erros de bit. 


A ideia principal que deve ficar guardada dessa discussão é que a definição de canais úteis envolve tanto 
entender os requisitos das aplicações quanto reconhecer as limitações da tecnologia subjacente. O desafio 


é preencher a lacuna entre o que a aplicação espera e o que a tecnologia subjacente pode oferecer. Isso às 
vezes é chamado de lacuna semântica. 





1.2.5 Facilidade de gerenciamento 


Um último requisito, que parece ser negligenciado ou frequentemente deixado para depois, é que as 
redes precisam ser gerenciadas. Gerenciar uma rede inclui fazer mudanças quando a rede cresce para 
transportar mais tráfego ou alcançar mais usuários e diagnosticar a rede quando as coisas saem errado 
ou o desempenho não é o desejado. 

Esse requisito está parcialmente relacionado à questão da escalabilidade, discutida anteriormente — 
como a Internet se expandiu para dar suporte a bilhões de usuários e pelo menos centenas de milhões 
de hosts, os desafios para manter a coisa toda funcionando corretamente e configurar corretamente 
os novos dispositivos à medida que são acrescentados se tornaram cada vez mais problemáticos. A 
configuração de um único roteador em uma rede normalmente é uma tarefa para um especialista 
treinado; configurar milhares de roteadores e descobrir por que uma rede desse tamanho não está se 
comportando conforme o esperado pode ser uma tarefa acima da capacidade de qualquer ser humano 
sozinho. Além do mais, para tornar a operação de uma rede escalável e econômica, os operadores de 
rede normalmente exigem que muitas tarefas de gerenciamento sejam automatizadas ou, pelo menos, 
realizadas por pessoal relativamente não habilitado. 

Um desenvolvimento importante no uso de redes desde que escrevemos a primeira edição deste 
livro é que elas agora são comuns nas residências. Isso significa que o gerenciamento da rede não é 
mais o domínio de especialistas, mas precisa ser realizado por consumidores com pouco ou nenhum 
treinamento especial. Isto é, às vezes, conhecido como um requisito de que os dispositivos de rede 
devem ser “plug-and-play” — um objetivo que provou ser bastante difícil de se alcançar. Mais adiante, 
iremos discutir algumas formas como esse requisito foi parcialmente tratado, mas por ora vale a pena 
observar que a melhoria da facilidade de gerenciamento das redes continua sendo uma área importante 
de pesquisas atuais. 


1.3 Arquitetura da rede 


Caso você ainda não tenha notado, a seção anterior estabeleceu um conjunto substancial de requisitos 
para o projeto de redes - uma rede de computadores precisa oferecer conectividade geral, econômica, 
justa e robusta entre uma grande quantidade de computadores. Como se isso não fosse suficiente, as 
redes não permanecem estáticas em qualquer ponto isolado no tempo, mas precisam evoluir para 
acomodar as mudanças tanto nas tecnologias subjacentes nas quais são baseadas como nas demandas 
impostas sobre elas por programas de aplicação. Ademais, as redes precisam ser gerenciáveis por 
humanos com diversos níveis de habilidade. O projeto de uma rede para atender a esses requisitos não 
é uma tarefa pequena. 

Para lidar com essa complexidade, os projetistas de rede desenvolveram esquemas gerais - normalmente 
chamados arquiteturas de rede — que orientam o projeto e a implementação das redes. Esta seção define 
mais cuidadosamente o que queremos dizer com uma arquitetura de rede, introduzindo as ideias cen- 
trais que são comuns a todas as arquiteturas de rede. Ela também apresenta duas das arquiteturas mais 
utilizadas — a arquitetura OSI (ou de sete camadas) e a arquitetura Internet. 


Conforme fizemos nesta seção. 
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1.3.1 Uso de camadas e protocolos 


Abstração — a ocultação de detalhes por trás de uma interface bem definida — é a ferramenta fundamental 
utilizada pelos projetistas de sistemas para administrar a complexidade. A ideia de uma abstração é 
definir um modelo que possa capturar algum aspecto importante do sistema, encapsular esse modelo 
em um objeto que ofereça uma interface que possa ser manipulada por outros componentes do sistema e 
ocultar dos usuários do objeto os detalhes de como esse objeto foi implementado. O desafio é identificar 
abstrações que, ao mesmo tempo, ofereçam um serviço útil em um grande número de situações e que 
possam ser eficientemente implementadas no sistema subjacente. Foi exatamente isso que fizemos ao 
introduzir a ideia de um canal na seção anterior: fornecemos uma abstração para as aplicações, a qual 
oculta a complexidade da rede das pessoas que escrevem aplicações. 

As abstrações naturalmente levam ao uso de camadas, especialmente nos sistemas em rede. A ideia 
geral é que você comece com os serviços oferecidos pelo hardware subjacente e depois acrescente uma 
sequência de camadas, cada uma fornecendo um nível de serviço mais alto (mais abstrato). Os serviços 
fornecidos nas camadas altas são implementados em termos dos serviços fornecidos pelas camadas 
baixas. Com base na discussão sobre requisitos, da seção anterior, poderíamos imaginar uma rede sim- 
ples como tendo duas camadas de abstração entre o aplicativo e o hardware subjacente, conforme ilustra 
a Figura 1.8. A camada imediatamente acima do hardware, neste caso, poderia oferecer conectividade 
host a host, abstraindo o fato de que pode haver uma topologia de rede bastante complexa entre os dois 
hosts. A próxima camada se baseia no serviço de comunicação host a host disponível e oferece suporte 
a canais processo a processo, abstraindo o fato de que a rede ocasionalmente perde mensagens, por 
exemplo. 

O uso de camadas fornece duas características interessantes. Primeiro, ele decompõe o problema de 
construir uma rede em componentes de mais fácil gerenciamento. Em vez de implementar um software 
monolítico, que faz tudo o que você porventura queira, é possível implementar várias camadas, cada 
uma solucionando uma parte do problema. Em segundo lugar, isso resulta em um projeto mais modular. 
Se você decidir que deseja acrescentar algum novo serviço, pode precisar modificar a funcionalidade 
em apenas uma camada, reutilizando as funções fornecidas em todas as outras camadas. 

Contudo, pensar em um sistema como uma sequência linear de camadas é uma simplificação ex- 
cessiva. Muitas vezes existem várias abstrações fornecidas em determinado nível do sistema, cada uma 
fornecendo um serviço diferente às camadas mais altas, mas baseando-se nas mesmas abstrações de 
nível mais baixo. Para ver isso, considere os dois tipos de canais discutidos na Seção 1.2.4: um oferece 
um serviço de solicitação /resposta e outro admite um serviço de fluxo de mensagens. Esses dois canais 
poderiam ser alternativas possíveis em algum nível de um sistema de redes multinível, conforme ilus- 
trado na Figura 1.9. 

Usando esta discussão de camadas como base, agora estamos prontos para discutir a arquitetura 
de uma rede com mais precisão. Primeiramente, os objetos abstratos que compõem as camadas de um 
sistema em rede são chamados de protocolos. Ou seja, um protocolo oferece um serviço de comunicação 
que os objetos de nível superior (como os processos da aplicação, ou talvez os protocolos de nível 
superior) utilizam para trocar mensagens. Por exemplo, poderíamos imaginar uma rede que suporta um 
protocolo de solicitação /resposta e um protocolo de fluxo de mensagens, correspondendo aos canais 
de solicitação/resposta e fluxo de mensagens discutidos anteriormente. 


Aplicativos Aplicativo 
? Canal de soli- Canal de fluxo de 
Canais processo a processo citação/resposta mensagens 
Conectividade host a host Conectividade host a host 
Hardware Hardware 
FIGURA 1.8 Exemplo de um sistema de rede em FIGURA 1.9 Sistema em camadas com abstrações 


camadas. alternativas disponíveis em determinada camada. 
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Cada protocolo define duas interfaces diferentes. Primeiro, ele define uma interface de serviço para os 
outros objetos no mesmo computador que queiram usar seus serviços de comunicação. Essa interface 
de serviço define as operações que os objetos locais podem realizar sobre o protocolo. Por exemplo, um 
protocolo de solicitação/resposta admitiria operações por meio das quais uma aplicação pode enviar 
e receber mensagens. Uma implementação do protocolo HTTP poderia suportar uma operação para 
buscar uma página de hipertexto de um servidor remoto. Uma aplicação como um navegador Web 
chamaria essa operação sempre que o navegador precisasse obter uma nova página (por exemplo, 
quando o usuário clica em um link na página sendo exibida no momento). 

Em segundo lugar, um protocolo define uma interface de par (ou peer interface) com seu correspondente 
(par) em outra máquina. Essa segunda interface define a forma e o significado das mensagens trocadas 
entre os pares de protocolos para implementar o serviço de comunicação. Isso determinaria o modo como 
um protocolo de solicitação /resposta em uma máquina se comunica com seu par em outra máquina. No 
caso do HTTP por exemplo, a especificação do protocolo define com detalhes como um comando GET é 
formatado, quais argumentos podem ser usados com o comando e como um servidor Web deve responder 
quando recebe tal comando. (Veremos esse protocolo em particular com mais detalhes na Seção 9.1.2.) 

Resumindo, um protocolo define um serviço de comunicação que ele exporta localmente (a interface 
de serviço), juntamente com um conjunto de regras controlando as mensagens que o protocolo troca 
com seu(s) par(es) para implementar esse serviço (a interface de par). Essa situação é ilustrada na 
Figura 1.10. 

Exceto no nível do hardware, em que os pares se comunicam diretamente uns com os outros por 
meio de um enlace, a comunicação par a par é indireta — cada protocolo se comunica com seu par 
passando mensagens para algum protocolo de nível inferior, que, por sua vez, entrega a mensagem ao 
seu par. Além disso, existem potencialmente vários protocolos em qualquer nível, cada um fornecendo 
um serviço de comunicação diferente. Portanto, representamos o conjunto de protocolos que compõem 
um sistema de rede com um grafo de protocolos. Os nós do grafo correspondem aos protocolos e as 
arestas representam uma relação depende de. Por exemplo, a Figura 1.11 ilustra um grafo de protocolos 
para o sistema hipotético em camadas que discutimos — protocolos de solicitação /resposta (PSR) e de 
fluxo de mensgaens (PFM) implementam dois tipos diferentes de canais processo a processo, e ambos 
dependem do protocolo host a host (PHH), que oferece um serviço de conectividade host a host. 

Neste exemplo, suponha que o programa de acesso a arquivos no host 1 queira enviar uma mensagem 
ao seu par no host 2 usando o serviço de comunicação oferecido pelo PSR. Nesse caso, a aplicação de 
arquivos pede ao PSR para enviar a mensagem por ele. Para se comunicar com seu par, o PSR chama 
os serviços do PHH, que, por sua vez, transmite a mensagem para seu par na outra máquina. Quando 
a mensagem tiver chegado na instância do PHH no host 2, o PHH passa a mensagem para o PSR acima 
dele, o qual, por sua vez, entrega a mensagem à aplicação de arquivos. Neste caso em particular, diz-se 
que a aplicação utiliza os serviços da pilha de protocolos PSR/PHH. 

Observe que o termo protocolo é usado de duas maneiras diferentes. Às vezes, ele se refere às in- 
terfaces abstratas — ou seja, às operações definidas pela interface de serviço e a forma e significado 
das mensagens trocadas entre os pares. Outras vezes, ele se refere ao módulo que de fato implementa 
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par a par FIGURA 1.10 Interfaces de serviço e interfaces de pares. 
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essas duas interfaces. Para distinguir entre as interfaces e o módulo que implementa essas interfaces, 
geralmente nos referimos às primeiras como especificações de protocolo. As especificações geralmente 
são expressas por meio de uma combinação de texto descritivo, pseudocódigo, diagramas de transição 
de estado, figuras de formatos de pacote e outras notações abstratas. Determinado protocolo pode ser 
implementado de diferentes maneiras por diferentes programadores, desde que cada um cumpra a 
especificação. O desafio é garantir que duas implementações diferentes da mesma especificação possam 
trocar mensagens com sucesso. Diz-se que dois ou mais módulos de protocolo que implementem com 
precisão uma especificação de protocolo interoperam um com o outro. 

Podemos imaginar muitos protocolos e grafos de protocolo diferentes que satisfazem os requisitos 
de comunicação de um conjunto de aplicações. Felizmente, existem agências de padronização, como o 
Internet Engineering Task Force (IETF) e a International Standards Organization (ISO), que estabelecem 
políticas para determinado grafo de protocolo. Chamamos de arquitetura de rede o conjunto de regras 
que controlam a forma e o conteúdo de um grafo de protocolo. Embora estejam fora do escopo deste 
livro, as agências de padronização estabeleceram procedimentos bem-definidos para a apresentação, 
validação e, finalmente, aprovação de protocolos em suas respectivas arquiteturas. Logo, descrevemos 
rapidamente as arquiteturas definidas pela IETF e pela ISO, mas primeiro existem duas outras coisas 
que precisamos explicar sobre a mecânica dos protocolos em camadas. 


Encapsulamento 

Considere o que acontece na Figura 1.11 quando um dos aplicativos envia uma mensagem ao seu par 
passando a mensagem ao PSR. Do ponto de vista do PSR, a mensagem que ele recebe da aplicação é 
uma sequência de bytes não interpretados. O PSR não se importa se esses bytes representam um vetor de 
inteiros, uma mensagem de e-mail, uma imagem digitalizada ou qualquer outra coisa; ele simplesmente 
está encarregado de enviá-los para seu par. Porém, o PSR precisa passar informações de controle ao seu 
par, instruindo-o sobre como lidar com a mensagem quando ela for recebida. O PSR faz isso anexando 
um cabeçalho à mensagem. Em termos gerais, um cabeçalho é uma pequena estrutura de dados — de 
alguns bytes a dezenas de bytes — que é usada entre os pares para se comunicarem uns com os outros. 
Como o nome sugere, os cabeçalhos normalmente são colocado no início de uma mensagem. Contudo, 
em alguns casos, essa informação de controle par a par é colocada no final da mensagem, caso em que 
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FIGURA 1.11 Exemplo de um grafo de protocolo. 
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é chamada de rodapé, ou trailer. O formato exato para o cabeçalho adicionado pelo PSR é definido por 
sua especificação de protocolo. O restante da mensagem - ou seja, os dados sendo transmitidos em 
nome da aplicação — é chamado de corpo ou payload (carga útil) da mensagem. Dizemos que os dados 
da aplicação são encapsulados na nova mensagem criada pelo PSR. 

Esse processo de encapsulamento é, então, repetido em cada nível do grafo de protocolo; por exem- 
plo, o PHH encapsula a mensagem do PSR anexando seu próprio cabeçalho. Se agora considerarmos 
que o PHH envia a mensagem ao seu par por meio de alguma rede, então, quando a mensagem chega 
no host de destino, ela é processada na ordem oposta: o PHH primeiro interpreta o cabeçalho PHH no 
início da mensagem (ou seja, toma qualquer ação apropriada dado o conteúdo do cabeçalho) e passa 
o corpo da mensagem (mas não o cabeçalho PHH) para o PSR, que toma qualquer ação indicada pelo 
cabeçalho PSR que seu par anexou e passa o corpo da mensagem (mas não o cabeçalho PSR) para o 
aplicativo. A mensagem passada do PSR para a aplicação no host 2 é exatamente a mesma mensagem 
que a aplicação passou para o PSR no host 1; a aplicação não enxerga qualquer um dos cabeçalhos 
que foram anexados a ela para implementar os serviços de comunicação nos níveis mais baixos. Esse 
processo inteiro é ilustrado na Figura 1.12. Observe que, neste exemplo, os nós na rede (por exemplo, 
switches e roteadores) podem inspecionar o cabeçalho PHH no início da mensagem. 

Observe que, quando dizemos que um protocolo de nível baixo não interpreta a mensagem que ele 
recebe por algum protocolo de nível mais alto, queremos dizer que ele não sabe como extrair qualquer 
significado dos dados contidos na mensagem. Porém, às vezes acontece que o protocolo de nível mais 
baixo aplica alguma transformação nos dados que ele recebe, por exemplo comprimindo-os ou cifran- 
do-os. Nesse caso, o protocolo está transformando o corpo inteiro da mensagem, incluindo os dados da 
aplicação original e todos os cabeçalhos anexados a esses dados por protocolos dos níveis mais altos. 


Multiplexação e demultiplexação 

Lembre-se, da Seção 1.2.3, que uma ideia fundamental da comutação de pacotes é multiplexar vários 
fluxos de dados em um único enlace físico. Essa mesma ideia se aplica acima e abaixo no grafo de 
protocolos, e não apenas aos nós de comutação. Na Figura 1.11, por exemplo, podemos pensar no PSR 
como implementando um canal de comunicação lógico, com mensagens de duas aplicações diferentes 
multiplexadas por esse canal no host de origem e, depois, demultiplexadas de volta para a aplicação 
apropriada no host de destino. 
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FIGURA 1.12 Mensagens de nível mais alto são encapsuladas dentro de mensagens de nível mais baixo. 
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Em termos práticos, isso significa simplesmente que o cabeçalho que o PSR anexa às suas mensa- 
gens contém um identificador que registra a aplicação à qual a mensagem pertence. Chamamos esse 
identificador de chave de demultiplexação do PSR, ou chave demux, para abreviar. No host de origem, 
o PSR inclui a chave demux apropriada em seu cabeçalho. Quando a mensagem é entregue ao PSR no 
host de destino, ele remove seu cabeçalho, examina a chave demux e demultiplexa a mensagem para 
a aplicação correta. 

O PSR não é o único a suportar multiplexação; quase todo protocolo implementa esse mecanismo. 
Por exemplo, o PHH tem sua própria chave demux para determinar quais mensagens passar para 
o PSR e quais passar para o PFM. Porém, não existe um acordo uniforme entre os protocolos — até 
mesmo aqueles dentro de uma mesma arquitetura de rede — sobre o que exatamente constitui uma 
chave demux. Alguns protocolos utilizam um campo de 8 bits (significando que podem aceitar apenas 
256 protocolos do nível acima), enquanto outros utilizam campos de 16 ou 32 bits. Além disso, alguns 
protocolos possuem um único campo de demultiplexação em seu cabeçalho, enquanto outros têm 
um par de campos de demultiplexação. No primeiro caso, a mesma chave demux é usada nos dois 
lados da comunicação, enquanto no segundo caso, cada lado usa uma chave diferente para identificar 
o protocolo de no nível acima (ou o aplicativo) ao qual a mensagem deve ser entregue. 


O modelo de sete camadas 
AISO foi uma das primeiras organizações a definir formalmente um modo comum conectar computado- 
res. Sua arquitetura, chamada arquitetura Open Systems Interconnection (OSI) e ilustrada na Figura 1.13, 
define um particionamento das funcionalidades da rede em sete camadas (ou níveis), onde um ou mais 
protocolos implementam a funcionalidade atribuída a cada camada. Nesse sentido, o esquema mostrado 
na Figura 1.13 não é um grafo de protocolos em si, mas sim um modelo de referência para um grafo de 
protocolos. Ele costuma ser chamado de modelo de sete camadas. 

Indo de baixo para cima, a camada física trata da transmissão de bits brutos por um enlace de comu- 
nicação. A camada de enlace de dados então coleta um fluxo de bits em um agregado maior, chamado de 
quadro ou frame. Os adaptadores de rede, junto com os gerenciadores de dispositivo sendo executados no 
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FIGURA 1.13 O modelo OSI de sete camadas. 





Capítulo 1 e Fundamentos 21 





ELSEVIER 


sistema operacional do nó, normalmente implementam o nível do enlace de dados. Isso significa que os 
quadros, e não os bits brutos, são de fato entregues aos hosts. A camada de rede trata do roteamento entre 
os nós dentro de uma rede de comutação de pacotes. Nessa camada, a unidade de dados trocada entre os 
nós normalmente é chamada de pacote, em vez de quadro, embora elas sejam fundamentalmente a mesma 
coisa. As três camadas mais baixas são implementadas em todos os nós da rede, incluindo switches dentro 
da rede e hosts conectados à borda da rede. A camada de transporte então implementa aquilo que chamamos 
até este ponto de canal processo a processo. Aqui, a unidade de dados trocada normalmente é chamada de 
mensagem, em vez de pacote ou quadro. A camada de transporte e as camadas mais altas normalmente 
são executadas apenas nos hosts finais e não nos switches ou roteadores intermediários. 

Existe menos acordo sobre a definição das três camadas superiores, em parte porque nem sempre 
elas estão todas presentes, conforme veremos em seguida. Saltando para a camada superior (a sétima), 
encontramos a camada de aplicação. Os protocolos da camada de aplicação incluem coisas como o 
Hypertext Transfer Protocol (HTTP), que é a base da World Wide Web e o que permite aos navegadores 
Web solicitarem páginas dos servidores Web. Abaixo dela, a camada de apresentação preocupa-se com 
o formato dos dados trocados entre os pares — por exemplo, se um inteiro tem 16, 32 ou 64 bits de 
comprimento, se o byte mais significativo é transmitido primeiro ou por último, ou como um fluxo 
de vídeo é formatado. Finalmente, a camada de sessão fornece um espaço de nomes que é usado para 
unir os fluxos de transporte potencialmente diferentes que fazem parte de uma única aplicação. Por 
exemplo, ela pode gerenciar um fluxo de áudio e um fluxo de vídeo que estão sendo combinados em 
uma aplicação de teleconferência. 


1.3.2 Arquitetura Internet 


A arquitetura Internet, que também, às vezes, é chamada de arquitetura TCP/IP indicando seus dois pro- 
tocolos principais, é representada na Figura 1.14. Uma representação alternativa aparece na Figura 1.15. A 
arquitetura Internet evoluiu a partir das experiências com uma rede de comutação de pacotes mais antiga, 
chamada ARPANET. Tanto a Internet quanto a ARPANET foram patrocinadas pela Advanced Research 
Projects Agency (ARPA), uma das agências de fomento à pesquisa e desenvolvimento do Departamento de 
Defesa dos Estados Unidos. A Internet e a ARPANET já existiam antes da arquitetura OSI, e a experiência 
obtida na sua criação foi uma influência importante no modelo de referência OSI. 

Embora o modelo OSI de sete camadas possa, com alguma imaginação, ser aplicado à Internet, um 
modelo de quatro camadas normalmente é usado em seu lugar. No nível mais baixo há uma série de 
protocolos de rede, indicados como REDE,, REDE, e assim por diante. Na prática, esses protocolos são 
implementados por uma combinação de hardware (por exemplo, um adaptador de rede) e software 
(por exemplo, um gerenciador de dispositivo de rede). Por exemplo, você poderia encontrar Ethernet 
ou protocolos sem fio (como os padrões Wi-Fi 802.11) nessa camada. (Esses protocolos, por sua vez, 
na realidade podem envolver várias subcamadas, mas a arquitetura Internet não pressupõe coisa 
alguma sobre elas.) A segunda camada consiste em um único protocolo — o Internet Protocol (IP). Esse 
é o protocolo que dá suporte à interconexão de várias tecnologias de rede em uma única interligação 
lógica de redes. A terceira camada contém dois protocolos principais - o Transmission Control Protocol 
(TCP) e o User Datagram Protocol (UDP). O TCP e o UDP oferecem canais lógicos alternativos para os 
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22 REDES DE COMPUTADORES ELSEVIER 


programas da camada de aplicação: o TCP oferece um canal de fluxo de bytes confiável, eo UDP oferece 
um canal de entrega de datagramas não confiável (datagrama pode ser considerado um sinônimo de 
mensagem). Na linguagem da Internet, TCP e UDP às vezes, são chamados de protocolos fim a fim, 
embora seja igualmente correto se referir a eles como protocolos de transporte. 

Executando acima da camada de transporte encontra-se uma série de protocolos de aplicação, como 
HTTP FTP Telnet (login remoto) e Simple Mail Transfer Protocol (SMTP), que permitem a interoperação 
de aplicações populares. Para entender a diferença entre um protocolo da camada de aplicação e uma 
aplicação, pense em todos os diferentes navegadores da World Wide Web que estão ou estiveram disponí- 
veis (por exemplo, Firefox, Safari, Netscape, Mosaic, Internet Explorer). Existe uma quantidade também 
grande de diferentes implementações de servidores Web. O motivo pelo qual você pode usar qualquer 
um desses aplicativos para acessar determinado site na Web é que todos eles estão em conformidade 
com o mesmo protocolo da camada de aplicação: o HTTP. Pode ser confuso que o mesmo termo às 
vezes se aplique a uma aplicação e ao protocolo da camada de aplicação que ela utiliza (por exemplo, 
FTP normalmente é usado como o nome de uma aplicação que implementa o protocolo FTP). 

A maioria das pessoas que trabalha ativamente na área de redes está acostumada com a arquitetura 
Internet e a arquitetura OSI de sete camadas, e existe um acordo geral sobre como as camadas são 
mapeadas entre as arquiteturas. A camada de aplicação da Internet é considerada como estando na 
camada 7, sua camada de transporte é a camada 4, a camada IP (interconexão de redes ou simplesmente 
rede) é a camada 3 e a camada de enlace ou sub-rede abaixo do IP é a camada 2. 

A arquitetura Internet apresenta três características que merecem destaque. Primeiro, como foi 
ilustrado na Figura 1.15, a arquitetura Internet não implica o uso estrito das camadas. A aplicação fica 
livre para contornar as camadas de transporte definidas e usar diretamente o IP ou uma das redes 
subjacentes. De fato, os programadores estão livres para definir novas abstrações de canal ou aplicações 
que são executadas em cima de qualquer um dos protocolos existentes. 

Em segundo lugar, se você examinar atentamente o grafo de protocolo da Figura 1.14, notará uma 
forma de ampulheta — larga no topo, estreita no meio e larga na parte de baixo. Essa forma realmente 
reflete a filosofia central da arquitetura. Ou seja, o IP serve como ponto focal para a arquitetura — ele 
define um método comum para trocar pacotes entre uma grande coleção de redes. Acima do IP pode 
haver qualquer quantidade de protocolos de transporte, cada um oferecendo uma abstração de canal 
diferente aos aplicativos. Assim, a questão de entregar mensagens de um host para outro é completa- 
mente separada da questão de fornecer um serviço de comunicação útil entre os processos. Abaixo do 
IP a arquitetura permite muitas tecnologias de rede diferentes, variando desde enlaces Ethernet até 
sem fios ou ponto a ponto dedicados. 

Um último atributo da arquitetura Internet (ou, mais exatamente, da cultura da IETF) é que, para 
que um novo protocolo seja oficialmente incluído na arquitetura, deve haver tanto uma especificação 
do protocolo como pelo menos uma (e, de preferência, duas) implementações representativas da 
especificação. A existência de implementações funcionais é exigida para que os padrões sejam adotados 
pela IETF Essa suposição cultural da comunidade de projeto ajuda a garantir que os protocolos da 
arquitetura possam ser implementados de modo eficiente. Talvez o valor que a cultura da Internet coloca 
sobre o software funcional seja mais bem exemplificado por uma citação em camisas normalmente 
usadas em reuniões da IETF: 


Nós rejeitamos reis, presidentes e votação. Nós acreditamos em consenso rígido e código funcional. 
(David Clark) 


Desses três atributos da arquitetura Internet, a filosofia de projeto em formato de ampulheta é importante 
o suficiente para a repetirmos aqui. A “cintura fina” da ampulheta representa um conjunto mínimo 
e cuidadosamente escolhido de capacidades globais que permite que aplicações no nível mais 


alto e tecnologias de comunicação no nível mais baixo coexistam, compartilhem capacidades e evoluam 
rapidamente. O modelo de “cintura fina” é crítico para a capacidade da Internet de adaptar-se rapidamente 
às novas demandas dos usuários e às mudanças nas tecnologias. 
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1.4 Implementando software de rede 


As arquiteturas de rede e as especificações de protocolo são coisas essenciais, mas um bom modelo 
não é suficiente para explicar o sucesso fenomenal da Internet: a quantidade de computadores conec- 
tados à Internet tem crescido exponencialmente por quase três décadas (embora seja difícil obter os 
números exatos). O número de usuários da Internet foi estimado em torno de 1,8 bilhão em 2009 - uma 
porcentagem impressionante da população mundial. 

O que explica o sucesso da Internet? Certamente, existem muitos fatores que colaboraram para isso 
(incluindo uma boa arquitetura), mas uma coisa que tornou a Internet um sucesso desenfreado é o fato de 
que grande parte de sua funcionalidade é oferecida por software sendo executado em computadores de 
uso geral. O significado disso é que novas funcionalidades podem ser acrescentadas prontamente 
com “uma simples questão de programação”. Como resultado, novas aplicações e serviços — comércio 
eletrônico, videoconferência e telefonia IP, para citar apenas alguns — têm aparecido em um ritmo 
incrível. 

Um fator relacionado é o aumento maciço no poder de computação disponível nas máquinas comu- 
mente disponíveis no mercado. Em princípio, embora as redes de computadores sempre tenham sido 
capazes de transportar qualquer tipo de informação, como amostras de voz digital, imagens digitalizadas 
e assim por diante, esse potencial não seria particularmente interessante se os computadores que enviam 
e recebem esses dados fossem lentos demais para fazer algo útil com a informação. Praticamente todos 
os computadores de hoje são capazes de reproduzir voz digitalizada e podem exibir vídeo em uma 
velocidade e resolução que são úteis para algumas aplicações (mas não para todas). Assim, as redes 
de hoje são cada vez mais usadas para transportar multimídia, e seu suporte para isso só melhorará à 
medida que o hardware de computação se tornar mais rápido. 

Nos anos seguintes ao lançamento da primeira edição deste livro, a criação de aplicações que 
usam a rede tornou-se uma atividade muito mais prevalente e menos uma tarefa para apenas al- 
guns especialistas. Muitos fatores influenciaram esse movimento, incluindo melhores ferramentas 
para facilitar o trabalho de não especialistas e a abertura de novos mercados, como as aplicações para 
smartphones. 

O ponto que devemos observar é que saber como implementar o software de rede é uma parte 
essencial da compreensão das redes de computadores, e embora provavelmente você não precisará 
implementar um protocolo de baixo nível como o IP há uma boa chance de você encontrar motivos 
para implementar um protocolo no nível da aplicação — a famosa “killer application” ou “aplicação 
formidável” que gerará fama e fortuna inimagináveis. Para começar, esta seção apresenta algumas das 
questões envolvidas na implementação de uma aplicação de rede em cima da Internet. Normalmente, 
esses programas são simultaneamente uma aplicação (ou seja, projetados para interagir com os usuários) 
e um protocolo (ou seja, comunicam-se com pares espalhados pela rede). O Capítulo 9 conclui o livro 
retornando ao assunto das aplicações de rede (protocolos no nível da aplicação), explorando vários 
exemplos populares. 


1.4.1 Interface de programação de aplicação (sockets) 


O lugar para começar quando implementamos uma aplicação em rede é a interface exportada pela 
rede. Como a maioria dos protocolos de rede é implementada em software (especialmente aqueles no 
alto da pilha de protocolos) e quase todos os sistemas de computação implementam seus protocolos de 
rede como parte do sistema operacional (SO), quando nos referimos à interface “exportada pela rede”, 
geralmente estamos nos referindo à interface que o SO fornece ao seu subsistema de rede. Essa interface 
normalmente é chamada de API (Application Programming Interface, ou Interface de Programação de 
Aplicativos) de rede. 

Embora cada sistema operacional seja livre para definir sua própria API de rede (e a maioria faz 
isso), com o tempo, certas APIs passaram a ter bastante suporte; ou seja, elas foram portadas para sis- 
temas operacionais diferentes do seu sistema nativo. Isso foi o que aconteceu com a interface de sockets 
fornecida originalmente pela distribuição Berkeley do Unix, que agora é aceita em praticamente todos 
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os sistemas operacionais populares, sendo o alicerce das interfaces específicas da linguagem, como a 
biblioteca de sockets Java. As vantagens do suporte da indústria a uma única API são que as aplicações 
podem ser facilmente portadas de um SO para outro e os desenvolvedores podem facilmente escrever 
aplicações para vários sistemas operacionais. 

Antes de descrever a interface de sockets, é importante manter dois aspectos separados na sua 
mente. Cada protocolo fornece certo conjunto de serviços, e a API fornece uma sintaxe pela qual esses 
serviços podem ser invocados em um sistema computacional em particular. A implementação é então 
responsável por mapear o conjunto tangível de operações e objetos definidos pela API para o conjunto 
abstrato de serviços definidos pelo protocolo. Se você tiver feito um bom trabalho de definição da in- 
terface, então será possível usar a sintaxe da interface para invocar os serviços de muitos protocolos 
diferentes. Essa generalização certamente foi um objetivo da interface de sockets, embora ela esteja 
longe de ser perfeita. 

A principal abstração da interface de sockets, logicamente, é o socket. Uma boa forma de pensar em 
um socket é como o ponto onde um processo local da aplicação se conecta à rede. A interface define 
operações para criar um socket, conectar o socket à rede, enviar/receber mensagens pelo socket e 
fechar o socket. Para simplificar a discussão, vamos nos limitar a mostrar como os sockets são usados 
com o TCP. 

O primeiro passo é criar um socket, o que é feito com a seguinte operação: 


int socket(int domain, int type, int protocol) 


O motivo para esta operação usar três argumentos é que a interface de sockets foi projetada para ser 
genérica o suficiente para dar suporte a qualquer conjunto de protocolos subjacente. Especificamente, o 
argumento domain (“domínio”) especifica a família de protocolos que será utilizada: PF INET indica a 
família Internet, PF UNIX indica a funcionalidade de pipe do Unix e PF PACKET indica o acesso direto à 
interface de rede (ou seja, isso contorna a pilha de protocolos TCP/IP). O argumento type (“tipo”) indica 
a semântica da comunicação. SOCK STREAM é usado para indicar um fluxo de bytes. SOCK DGRAM 
é uma alternativa que indica um serviço orientado a mensagens, como aquele oferecido pelo UDP O 
argumento protocol (“protocolo”) identifica o protocolo específico que será usado. Em nosso caso, esse 
argumento é UNSPEC, pois a combinação de PF INET e SOCK STREAM implica em TCP Por fim, o 
valor de retorno do socket é um identificador para o socket recém-criado — ou seja, um identificador pelo 
qual poderemos nos referir ao socket no futuro. Ele é fornecido como um argumento para operações 
subsequentes sobre esse socket. 

O próximo passo depende se você é um cliente ou um servidor. Em uma máquina servidora, o 
processo da aplicação realiza uma abertura passiva — o servidor diz que está preparado para aceitar 
conexões, mas não estabelece de fato uma conexão. O servidor faz isso invocando as três operações 
a seguir: 


int bind(int socket, struct sockaddr “address, int addr _len) 
int listen(int socket, int backlog) 


int accept(int socket, struct sockaddr “address, int “addr len) 


A operação bind (“vincular”) como o nome sugere, vincula o socket recém-criado ao address 
(“endereço”) especificado. Este é o endereço de rede do participante local - o servidor. Observe 
que, quando usado com protocolos da Internet, address é uma estrutura de dados que inclui tanto 
o endereço IP do servidor como um número de porta TCP. (Conforme veremos no Capítulo 5, as 
portas são usadas para identificar processos indiretamente. Elas são uma forma de chaves demux, 
conforme definimos na Seção 1.3.1.) O número de porta normalmente é algum número conhecido, 
específico do serviço sendo oferecido; por exemplo, os servidores Web normalmente aceitam 
conexões na porta 80. 
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Em seguida, a operação listen (“escutar”) define quantas conexões podem estar pendentes no socket 
especificado. Finalmente, a operação accept (“aceitar”) executa a abertura passiva. Essa é uma operação 
bloqueante que não retorna até que um participante remoto tenha estabelecido uma conexão, e quando 
a conexão é completada ela retorna um novo socket que corresponde a essa conexão recém-estabelecida; 
o seu argumento address contém o endereço do participante remoto. Observe que, quando a operação 
de accept retorna, o socket original que foi passado como argumento ainda existe e ainda se encontra 
no estado de abertura passiva; ele é usado em chamadas futuras de accept. 

Na máquina do cliente, o processo da aplicação realiza uma abertura ativa, ou seja, ele diz com quem 
ele quer se comunicar invocando a operação isolada a seguir: 


int connect(int socket, struct sockaddr “address, int addr len) 


Essa operação não retorna até que o TCP tenha estabelecido uma conexão com sucesso,* quando a 
aplicação fica livre para começar a enviar dados. Nesse caso, address contém o endereço do participante 
remoto. Na prática, o cliente normalmente especifica apenas o endereço do participante remoto e deixa 
que o sistema preencha a informação local. Embora um servidor normalmente escute mensagens em 
uma porta bem conhecida, um cliente normalmente não se importa com qual porta ele usa para si; o 
SO simplesmente seleciona uma porta não utilizada. 

Quando uma conexão é estabelecida, os processos da aplicação chamam as duas operações a seguir 
para enviar e receber dados: 


int send(int socket, char “message, int msg _len, int flags) 
int recv(int socket, char “buffer, int buf _len, int flags) 


A primeira operação envia pelo socket especificado a message (“mensagem”) passada como parâme- 
tro, enquanto a segunda operação recebe uma mensagem do socket especificado e a coloca no buffer 
indicado. As duas operações usam um conjunto de flags (“marcadores”) que controlam certos detalhes 
da operação. 


1.4.2 Exemplo de aplicação 


Agora, mostramos a implementação de um programa cliente/servidor simples, que usa a interface de 
sockets para enviar mensagens por uma conexão TCP O programa também usa outros utilitários de rede 
do Unix, que apresentaremos à medida que eles aparecerem. Nossa aplicação permite que um usuário 
em uma máquina digite e envie texto a um usuário em outra máquina. Essa é uma versão simplificada 
do programa talk (“conversar”) do Unix, que é semelhante ao programa no núcleo de uma aplicação de 
mensagem instantânea. 


Cliente 

Começamos com o lado do cliente, que recebe o nome da máquina remota como argumento. Ele in- 
voca o utilitário gethostbyname (“obter host a partir do nome”) do Unix para traduzir esse nome para 
o endereço IP do host remoto. O próximo passo é construir a estrutura de dados relativa ao endereço 
(sin) esperada pela interface de sockets. Observe que essa estrutura de dados especifica que usaremos o 
socket para nos conectarmos à Internet (AF INET). Em nosso exemplo, usamos a porta TCP 5432 como 
a porta bem conhecida do servidor; acontece que esta é uma porta que não foi atribuída a qualquer 
outro serviço da Internet. A última etapa no estabelecimento da conexão é invocar socket e connect. 
Quando a operação connect retorna, a conexão é estabelecida e o programa cliente entra no seu laço 
principal, que lê texto proveniente da entrada padrão e o envia pelo socket. 


“Obviamente, a operação também retorna caso haja um erro (por exemplo, se o servidor recusar a conexão por algum 
motivo) (N.T.) 


26 REDES DE COMPUTADORES 


tinclude <stdio.h> 
tinclude <sys/types.h> 
finclude <sys/socket.h> 
tinclude <netinet/in.h> 
finclude <netdb.h> 


tdefine SERVER PORT 5432 
fdefine MAX LINE 256 


int 


main(int argc, char + argv[]) 


{ 


FILE fp; 

struct hostent +hp; 
struct sockaddr in sin; 
char +host; 

char buf [MAX LINE]; 

int s; 

int len; 


if (argc==2) ( 
host = argv[1]; 
} 
else { 
fprintf (stderr, “usage: simplex-talk host\n”); 
exit (1); 
+ 
/x traduz nome do host para endereço IP do host «/ 
hp = gethostbyname (host) ; 
if (!hp) ( 
fprintf(stderr, “simplex-talk: unknown host: &sin”, host); 
exit (1); 


/x monta estrutura de dados do endereço «/ 

bzero((char +)«sin, sizeof(sin)); 

sin.sin family = AF INET; 

bcopy (hp->h addr, (char +)&sin.sin addr, hp->h length); 
sin.sin port = htons (SERVER PORT) ; 


/x abertura ativa «/ 
if ((s = socket (PF INET, SOCK STREAM, 0)) < 0) { 
perror (“simplex-talk: socket”); 
exit (1); 
} 
if (connect (s, (struct sockaddr *)}&sin, sizeof (sin)) < 0) 
( 
perror (“simplex-talk: connect”); 
close(s); 
exit(1); 


/» laço principal: obtém e envia linhas de texto x/ 
while (fgets (buf, sizeof(buf), stdin)) { 

buf [MAX LINE-1] = “N0"; 

len = strlen(buf) + 1; 

send(s, buf, len, 0); 


ELSEVIER 
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Servidor 

O servidor também é muito simples. Primeiro, ele constrói a estrutura de dados referente ao endereço 
preenchendo seu próprio número de porta (SERVER PORT). Como ele não especifica um endereço 
IP o aplicativo está disposto a aceitar conexões em qualquer um dos endereços IP do host local. Em 
seguida, o servidor realiza as etapas preliminares envolvidas em uma abertura passiva; ele cria o socket, o 
vincula ao endereço local e define o número máximo de conexões pendentes permitidas. Por fim, o laço 
principal espera até que um host remoto tente se conectar e, quando algum host fizer isso, o aplicativo 
recebe e imprime os caracteres que chegam pela conexão. 


tinclude <stdio.h> 
tinclude <sys/types.h> 
ftinclude <sys/socket .h> 
finclude <neLinet/in.h> 
tinclude <netdb.n> 


tdefine SERVER PORT 
#define MAX PENDING 
#define MAX LINE 25 


a u 


$) 


len] 


int 
main () 
{ 
struct sockaddr_in sin; 
char buf [MAX LINE]; 
int len; 
int s, new s; 


/x monta estrutura de dados de endereço «/ 
bzero( (char +)&sin, sizeof(sin)); 

sin.sin family = AF INET; 

sin.sin addr.s addr = INADDR ANY; 

sin.sin port = htons (SERVER PORT); 


/x prepara abertura passiva «/ 
if ((s = socket (PF INET, SOCK STREAM, 0)) < 0) 1 
perror (“simplex-talk: socket”); 
exit(1); 
} 
if ((bind(s, (struct sockaddr +)&sin, sizeof(sin))) < 0) { 
perror (“simplex-talk: bind”); 
exit(1); 
} 
listen (s, MAX PENDING) ; 


/x espera conexão, depois recebe e imprime texto +/ 
wnile(1l) { 
if ((new s = accept(s, (struct sockaddr +)&sin, &len)) < 0) { 
perror (“simplex-talk: accept”); 
exit (1); 
j> 
while (len = recv(new s, buf, sizeof(buf), 0)) 
fputs (buf, stdout); 
close(new s); 
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1.5 Desempenho 


Até este ponto, nos concentramos principalmente nos aspectos funcionais da rede. Porém, assim como 
qualquer sistema computacional, também se espera que as redes de computadores tenham um bom 
desempenho. Isso porque a eficiência da computação distribuída pela rede normalmente depende dire- 
tamente da eficiência com que a rede entrega os dados usados na computação. Embora o velho ditado da 
programação “primeiro faça-o certo e depois faça-o rápido” seja válido em muitas situações, com as redes 
normalmente é necessário “projetar para o desempenho”. Portanto, é importante entender os diversos 
fatores que afetam o desempenho da rede. 


1.5.1 Largura de banda e latência 


O desempenho da rede é medido de duas maneiras fundamentais: largura de banda (também chamada 
de vazão) e latência (também chamada de atraso). A largura de banda de uma rede é dada pelo número de 
bits que podem ser transmitidos pela rede em certo período de tempo. Por exemplo, uma rede poderia 
ter uma largura de banda de 10 milhões de bits/segundo (Mbps), significando que ela é capaz de 
entregar 10 milhões de bits a cada segundo. Às vezes é útil pensar na largura de banda em termos de 
quanto tempo é necessário para transmitir cada bit de dados. Em uma rede de 10 Mbps, por exemplo, 
é necessário 0,1 microssegundo (us) para transmitir cada bit. 

Embora se possa falar sobre largura de banda da rede como um todo, às vezes deseja-se ser mais 
preciso, focalizando, por exemplo, a largura de banda de um único enlace físico ou de um canal processo 
a processo. No nível físico, a largura de banda está constantemente melhorando, sem qualquer fim em 
vista. ntuitivamente, se você pensar em um segundo de tempo como uma distância que pudesse ser 
medida com uma régua e a largura de banda como a quantidade de bits que cabem nessa distância, 
então poderá pensar em cada bit como um pulso de certo comprimento. Por exemplo, cada bit em um 
enlace de 1 Mbps tem 1 us de comprimento, enquanto cada bit em um enlace de 2 Mbps tem 0,5 us de 
comprimento, conforme ilustrado na Figura 1.16. Quanto mais sofisticada a tecnologia de transmissão e 
recepção, mais curto pode ser cada bit e, assim, maior a largura de banda. Para os canais lógicos processo 
a processo, a largura de banda também é influenciada por outros fatores, incluindo quantas vezes o 
software que implementa o canal precisa tratar e possivelmente transformar cada bit de dados. 


LARGURA DE BANDA E VAZÃO 


Largura de banda e vazão são dois dos termos mais confusos usados em redes. Embora pudéssemos tentar 
oferecer ao leitor uma definição precisa de cada termo, é importante que você saiba como outras pessoas 
poderiam usá-los e que você esteja ciente de que eles normalmente são usados para indicar a mesma coisa. 
Em primeiro lugar, a largura de banda é literalmente uma medida da largura de uma banda de frequência. 
Por exemplo, uma linha telefônica para transmissão de voz admite uma faixa de frequência que varia de 300 a 
3.300 Hz; diz-se que ela tem uma largura de banda de 3.300 Hz — 300 Hz = 3.000 Hz. Se você encontrar o termo 
largura de banda usado em uma situação em que ela está sendo medida em hertz, então provavelmente ele 
se refere à faixa de sinais que podem ser acomodados. 

Quando falamos sobre a largura de banda de um enlace de comunicação, normalmente nos referimos 
ao número de bits por segundo que podem ser transmitidos no enlace. Isso, às vezes, é chamado de taxa de 
dados. Poderíamos dizer que a largura de banda de um enlace Ethernet é 10 Mbps. Porém, uma distinção útil 
também pode ser feita entre a taxa de dados máxima disponível no enlace e o número de bits por segundo que 
podemos realmente transmitir pelo enlace na prática. Costumamos usar o termo vazão (ou throughput) para 
nos referirmos ao desempenho medido de um sistema. Assim, devido a várias ineficiências da implantação, um 
par de nós conectados por um enlace com uma largura de banda de 10 Mbps poderia alcançar uma vazão de 
apenas 2 Mbps. Isso significaria que uma aplicação em um host poderia enviar dados ao outro host a 2 Mbps. 

Finalmente, costumamos falar sobre requisitos de largura de banda de uma aplicação. Esse é o número 
de bits por segundo que ela precisa transmitir pela rede para funcionar de modo aceitável. Para algumas 
aplicações, isso poderia ser “o quanto for possível”; para outras, poderia ser algum número fixo (de 
preferência, não mais do que a largura de banda disponível no enlace); e para outras, poderia ser um número 
que varia com o tempo. Vamos tratar melhor desse assunto em outro ponto desta seção. 
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(a) FIGURA 1.16 Bits transmitidos em determinada largura de banda podem 
ser considerados como tendo um certo comprimento: (a) bits transmitidos 
| na | a 1 Mbps (cada bit tem 1 us de comprimento); (b) bits transmitidos a 2 
1 segundo Mbps (cada bit tem 0,5 us de comprimento). 





(b) 





1 segundo 


A segunda medida de desempenho, a latência, corresponde ao tempo gasto para uma mensagem 
atravessar de uma extremidade da rede a outra. (Assim como na largura de banda, poderíamos nos 
concentrar na latência de um único enlace ou de um canal fim a fim.) A latência é medida estritamente 
em termos de tempo. Por exemplo, uma rede transcontinental poderia ter uma latência de 24 milisse- 
gundos (ms); ou seja, uma mensagem gasta 24 ms para atravessar de uma costa da América do Norte 
até a outra. Existem muitas situações em que é mais importante saber quanto tempo é gasto para enviar 
uma mensagem de uma extremidade da rede até a outra e voltar, em vez da latência apenas de ida. 
Chamamos isso de tempo de ida e volta (RTT — Round-Trip Time) da rede. 

Normalmente, pensamos na latência como tendo três componentes. Primeiro, existe o atraso da 
propagação na velocidade da luz. Esse atraso ocorre porque nada, incluindo um bit em um fio, pode 
viajar mais rápido do que a velocidade da luz. Se você souber a distância entre dois pontos, poderá 
calcular a latência na velocidade da luz, embora precise ter cuidado, pois a luz atravessa meios dife- 
rentes em velocidades diferentes: ela viaja a 3,0 x 10ºm/s no vácuo, a 2,3 x 10ºm/s em um cabo de 
cobre e a 2,0 x 108m/s em uma fibra óptica. Em segundo lugar, existe o tempo gasto para transmitir 
uma unidade de dados. Isso é uma função da largura de banda da rede e do tamanho do pacote em 
que os dados são transportados. Em terceiro lugar, pode haver atrasos de enfileiramento dentro da 
rede, pois os switches de pacotes geralmente precisam armazenar pacotes por algum tempo antes 
de encaminhá-los por um enlace de saída, conforme discutimos na Seção 1.2.3. Assim, poderíamos 
definir a latência total como 


Latência = Propagação + Transmissão + Fila 
Propagação = Distância/VelocidadeDaLuz 
Transmissão = Tamanho/LarguraDeBanda 


onde a Distância é o comprimento do fio no qual os dados trafegarão, VelocidadeDaLuz é a velocidade 
efetiva da luz nesse fio, Tamanho é o tamanho do pacote e LarguraDeBanda é a largura de banda em 
que o pacote é transmitido. Observe que, se a mensagem tiver apenas um bit e estivermos falando de 
um único enlace (não de uma rede inteira), então os termos Transmissão e Fila não são relevantes, e a 
latência corresponde apenas ao atraso de propagação. 

Largura de banda e latência são combinadas para definir as características de desempenho 
de determinado enlace ou canal. Porém, sua importância relativa depende da aplicação. Para 
algumas aplicações, a latência domina a largura de banda. Por exemplo, um cliente que envia 
uma mensagem de 1 byte a um servidor e recebe uma mensagem de 1 byte de volta tem a latência 
como fator limitante. Supondo que nenhuma computação séria esteja envolvida na preparação 
da resposta, a aplicação funcionará de forma muito diferente em um canal transcontinental, com 
um RTT de 100 ms, quando comparado a um canal dentro da mesma sala, com um RTT de 1 ms. 
Porém, o fato de o canal ter 1 Mbps ou 100 Mbps é relativamente insignificante, pois o primeiro 
caso implica que o tempo para transmitir um byte (Transmissão) é de 8 us e o segundo implica que 
Transmissão = 0,08 us. 

Por outro lado, considere um programa de biblioteca digital, que está sendo solicitado a buscar uma 
imagem de 25 megabytes (MB) - quanto mais largura de banda disponível, mais rápido ele poderá 
retornar a imagem ao usuário. Aqui, a largura de banda do canal domina o desempenho. Para ver is- 
so, suponha que o canal tenha uma largura de banda de 10 Mbps. São necessários 20 segundos para 
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FIGURA 1.17 Latência percebida (tempo de resposta) em função do tempo de ida e volta para diversos tamanhos de objeto e 
velocidades de enlace. 


transmitir a imagem (25 x 10º x 8 bits + 10 x 10º Mbps=20 segundos), tornando relativamente pouco 
importante se a imagem está no outro lado de um canal de 1 ms ou de um canal de 100 ms; a diferença 
entre um tempo de resposta de 20,001 segundos e 20,1 segundos é insignificante. 

A Figura 1.17 dá uma ideia de como a latência ou a largura de banda podem dominar o desempe- 
nho em diferentes circunstâncias. O gráfico mostra quanto tempo é necessário para mover objetos de 
diversos tamanhos (1 byte, 2 KB, 1 MB) por redes com RTTs que variam de 1 a 100 ms e velocidades de 
enlace de 1,5 ou 100 Mbps. Usamos escalas logarítmicas para mostrar o desempenho relativo. Para um 
objeto de 1 byte (digamos, um toque de tecla), a latência continua quase exatamente igual ao RTT, de 
modo que você não é capaz de distinguir entre uma rede de 1,5 Mbps e uma rede de 10 Mbps. Para um 
objeto de 2 KB (digamos, uma mensagem de e-mail), a velocidade do enlace faz muita diferença em 
uma rede com RTT de 1 ms, mas a diferença é insignificante em uma rede com RTT de 100 ms. E para 
um objeto de 1 MB (digamos, uma imagem digital), o RTT não faz diferença — é a velocidade do enlace 
que domina o desempenho por toda a faixa de RTTs citados. 

Observe que, no decorrer deste livro, usamos os termos latência e atraso como uma forma genérica 
de indicar quanto tempo é necessário para realizar determinada função, como entregar uma mensagem 
ou mover um objeto. Quando estamos nos referindo à quantidade de tempo específica necessária 
para um sinal se propagar de uma extremidade de um enlace para outra, usamos o termo atraso de 
propagação. Além disso, o contexto da discussão deixará claro se estamos nos referindo à latência de 
ida ou ao tempo de ida e volta. 

Observe que os computadores estão se tornando tão rápidos que, quando são conectados às redes, 
às vezes é útil pensar, pelo menos de forma figurada, em termos de instruções por quilômetro. Considere 
o que acontece quando um computador que é capaz de executar 1 bilhão de instruções por segundo 
envia uma mensagem em um canal com um RTT de 100 ms. (Para facilitar a matemática, suponha que 
a mensagem cubra uma distância de 5.000 quilômetros.) Se esse computador ficar ocioso por todos 
os 100 ms em que espera uma mensagem de resposta, então ele abriu mão da capacidade de executar 
100 milhões de instruções, ou 20.000 instruções por quilômetro. É melhor que essa transmissão dos 
dados para a rede justifique o tempo desperdiçado. 
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FIGURA 1.18 A rede como um tubo. 





1.5.2 Produto atraso x largura de banda 


Também é útil falar sobre o produto dessas duas medidas, normalmente chamado produto atraso x lar- 
gura de banda. Intuitivamente, se imaginarmos um canal entre um par de processos como um tubo oco 
(ver Figura 1.18), onde a latência corresponde ao comprimento do tubo e a largura de banda fornece 
o diâmetro do tubo, então o produto atraso x largura de banda fornece o volume do tubo — o número 
máximo de bits que poderiam estar em trânsito no tubo em qualquer instante. Em outras palavras, se a 
latência (medida em unidades de tempo) corresponde ao comprimento do tubo, então, dada a largura 
de cada bit (também medida em unidades de tempo), você pode calcular quantos bits cabem no tubo. 
Por exemplo, um canal transcontinental com uma latência de ida de 50 ms e uma largura de banda de 
45 Mbps poderá conter 


50x 10-3sx45x10ºbits/s 
=2,25x10ºbits 


ou aproximadamente 280 KB de dados. Em outras palavras, este canal de exemplo (tubo) arma- 
zena tantos bytes quanto a memória de um computador do início da década de 1980 poderia 
armazenar. 

É importante conhecer o produto atraso x largura de banda na construção de redes de alto de- 
sempenho, pois ele corresponde a quantos bits o emissor deverá transmitir antes que o primeiro bit 
chegue ao receptor. Se o emissor estiver esperando que o receptor, de alguma maneira, sinalize que os 
bits estão começando a chegar, e houver latência adicional do canal para que esse sinal se propague 
de volta ao emissor, então o emissor pode enviar até um RTT x largura de banda de dados antes de 
receber do receptor a informação de que tudo está bem. Os bits no tubo são considerados “a caminho”, 
o que significa que, se o receptor disser ao emissor para parar de transmitir, ele pode receber até um 
RTT x largura de banda de dados antes que o emissor consiga responder. Em nosso exemplo anterior, 
essa quantidade corresponde a 5,5 x 10º (671 KB) de dados. Entretanto, se o emissor não preencher o 
tubo — enviar um produto RTT x largura de banda de dados antes de parar para esperar um sinal —, o 
emissor não utilizará a rede completamente. 

Observe que, na maior parte do tempo, estaremos interessados no cenário do RTT, que simplesmente 
chamamos de produto atraso X largura de banda, sem dizer explicitamente que “atraso” é o RTT (ou seja, 
o atraso de ida multiplicado por dois). Normalmente, podemos descobrir pelo contexto se o “atraso” 
no produto “atraso x largura de banda” significa a latência de ida ou o RTT. A Tabela 1.1 mostra alguns 
exemplos de produtos RTT x largura de banda para alguns enlaces de rede típicos. 


Tabela 1.1 Exemplos de produtos atraso x largura de banda 





Largura de banda Distância de ida Atraso de ida RTT x Largura 
Tipo de enlace (típica) (típica) e volta de banda 
Discado (Dial-up) 56 kbps 10 km 87 us 5 bits 
LAN sem fio 54 Mbps 50 m 0,33us 18 bits 
Satélite 45 Mbps 35.000 km 230 ms 10 Mb 


Fibra atravessando o país 10 Gbps 4.000 km 40 ms 400 Mb 
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QUAL É O TAMANHO DE UM MEGA? 


Existem várias armadilhas que você precisa conhecer ao trabalhar com as unidades comuns da rede — MB, 
Mbps, KB e kbps. A primeira é distinguir cuidadosamente entre bits e bytes. No decorrer deste livro, sempre 
usamos uma letra b minúscula para bits e uma letra B maiúscula para bytes. A segunda é ter certeza de estar 
usando a definição apropriada de mega (M) e quilo (K). Mega, por exemplo, pode significar 22º ou 10º. Da 
mesma forma, quilo pode ser 2!º ou 10°. Pior que isso, normalmente usamos as duas definições quando 
tratamos de redes. Vejamos por quê. 

A largura de banda da rede, que normalmente é especificada em termos de Mbps, normalmente é 
controlada pela velocidade do relógio (clock) que define o ritmo da transmissão dos bits. Um relógio 
funcionando a 10 MHz é usado para transmitir bits a 10 Mbps. Como o mega em MHz significa 10º hertz, 
Mbps normalmente também é definido como 10º bits por segundo. (De modo semelhante, kbps é 10º bits 
por segundo.) Entretanto, quando falamos sobre uma mensagem que queremos transmitir, normalmente 
indicamos seu tamanho em kilobytes. Como as mensagens são armazenadas na memória do computador, 

e a memória normalmente é medida em potências de dois, o K em KB normalmente é considerado 21º. (De 
modo semelhante, MB normalmente significa 27.) Quando você junta os dois, não é raro falarmos sobre 
enviar uma mensagem de 32 KB por um canal de 10 Mbps, o que deveria ser interpretado como 32 x 21º x 8 
bits estão sendo transmitidos a uma taxa de 10 x 108 bits por segundo. Essa é a interpretação que usamos em 
todo o livro, a menos que seja indicado explicitamente de outra forma. 

A boa notícia é que, muitas vezes, nos contentamos com um cálculo aproximado, quando é perfeitamente 
razoável fazer uma aproximação de que 10º na realidade é igual a 2” (facilitando a conversão entre as 
duas definições de mega). Essa aproximação introduz um erro de apenas 5%. Podemos até mesmo fazer 
a aproximação em alguns casos de que um byte tem 10 bits, um erro de 20% mas bom o suficiente para 
estimativas na mesma ordem de grandeza. 

Para ajudá-lo nos seus cálculos aproximados, 100 ms é um número razoável para usar como um tempo 
de ida e volta atravessando um país — pelo menos, quando o país em questão é os Estados Unidos — e 1 ms 
é uma boa aproximação de um RTT para uma rede local. No caso do primeiro, aumentamos o tempo de 
ida e volta de 48 ms implicado pela velocidade da luz em uma fibra para o valor de 100 ms, pois existem, 
como dissemos, outras fontes de atraso, como o tempo de processamento nos switches dentro da rede. Você 
também pode ter certeza de que o caminho seguido pela fibra entre dois pontos não será uma linha reta. 





“Para tentar solucionar esta confusão, a International Electrotechnical Commission (TEC) publicou em 1999 um padrão 
(TEC 60027-2: Telecommunications and electronics) que dita a adição da letra 'i' para indicar potências de 2 em vez de 
potências de 10, ou seja, 1 Ki=210, 1 Mi=220 etc. Apesar de amplamente aceito por órgãos de padronização, seu uso ainda 
é pouco comum na prática (N.T.). 





1.5.3 Redes de alta velocidade 


As larguras de banda disponíveis nas redes de hoje estão aumentando em um ritmo incrível, e existe 
um otimismo eterno de que a largura de banda das redes continuará a melhorar. Isso faz com que os 
projetistas de redes comecem a pensar no que acontecerá no limite ou, em outras palavras, qual é o 
impacto sobre o projeto da rede de ter largura de banda infinita à disposição. 

Embora as redes de alta velocidade tragam uma mudança incrível na largura de banda disponível 
às aplicações, em muitos aspectos, seu impacto sobre como pensamos nas redes está naquilo que não 
muda quando uma largura de banda aumenta: a velocidade da luz. Citando Scotty, de Start Trek: “Ye 
cannae change the laws of physics”.º Em outras palavras, a “alta velocidade” não significa que a latência 
melhora no mesmo ritmo da largura de banda; o RTT transcontinental de um enlace de 1 Gbps são os 
mesmos 100 ms de um enlace de 1 Mbps. 

Para apreciar o significado da largura de banda cada vez maior diante da latência fixa, considere o 
que é necessário para transmitir um arquivo de 1 MB por uma rede de 1 Mbps em comparação com uma 


Em dialeto escocês: “Você não pode mudar as leis da física”. 
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FIGURA 1.19 Relação entre largura de banda e latência. Um arquivo de 1 MB preencheria o enlace de 1 Mbps 80 vezes, mas só 
preencheria o enlace de 1 Gbps por 1/12 do tempo. 


rede de 1 Gbps, ambas com um RTT de 100 ms. No caso da rede de 1 Mbps, são necessários 80 tempos 
de ida e volta para transmitir o arquivo; durante cada RTT, 1,25% do arquivo é enviado. Por outro lado, 
o mesmo arquivo de 1 MB nem sequer chega perto de preencher 1 RTT do enlace de 1 Gbps, que possui 
um produto atraso X largura de banda de 12,5 MB. 

A Figura 1.19 ilustra a diferença entre as duas redes. De fato, o arquivo de 1 MB toma o aspecto de 
um fluxo de dados que precisa ser transmitido por uma rede de 1 Mbps, enquanto se parece com um 
único pacote em uma rede de 1 Gpbs. Para ajudar a compreender melhor esse ponto, considere que 
um arquivo de 1 MB está para uma rede de 1 Gpbs assim como um pacote de 1 KB está para uma rede 
de 1 Mbps. 


Outra forma de pensar na situação é que mais dados podem ser transmitidos durante cada RTT em uma rede 
de alta velocidade, tanto que um único RTT torna-se uma quantidade de tempo significativa. Assim, embora 
você não pense duas vezes sobre a diferença entre uma transferência de arquivo levando 101 RTTs ao invés 


de 100 RTTs (uma diferença relativa de apenas 1%), de repente a diferença entre 1 RTT e 2 RTTs é significativa — 
um aumento de 100%. Em outras palavras, a latência, e não a vazão, começa a dominar nosso raciocínio com 
relação ao projeto de redes. 





Talvez a melhor maneira de entender a relação entre vazão e latência seja retornar aos fundamentos. 
A vazão fim a fim efetiva que pode ser alcançada por uma rede é dada pela relação simples 


Vazão = TamanhoTransferência/Tempo Transferência 


onde TempoTransferência inclui não apenas os elementos da Latência de ida identificada anteriormente 
nesta seção, mas também qualquer tempo adicional gasto solicitando ou configurando a transferência. 
Em geral, representamos essa relação como 


TempoTransferência = RTT + 1/Largura de banda x TamanhoTransferência 


Usamos o RTT nesse cálculo para considerar uma mensagem de solicitação sendo enviada pela 
rede e os dados sendo retornados. Por exemplo, considere uma situação onde um usuário deseja 
obter um arquivo de 1 MB por uma rede de 1 Gbps com um tempo de ida e volta de 100 ms. O 
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TempoTransferência inclui tanto o tempo de transmissão de dados de 1 MB (1/1 Gbpsx 1 MB=8 
ms) e o RTT de 100 ms, gerando um tempo de transferência total de 108 ms. Isso significa que a 
vazão efetiva será 


1 MB/108 ms = 74,1 Mbps 


e não 1 Gbps. Claramente, a transferência de uma quantidade maior de dados ajudará a melhorar a 
vazão efetiva em que, no limite, um tamanho de transferência infinitamente grande fará com que a 
vazão efetiva se aproxime da largura de banda da rede. Por outro lado, ter que enfrentar mais do que 
1 RTT - por exemplo, para retransmitir pacotes perdidos — prejudicará a vazão efetiva para qualquer 
transferência de tamanho finito e será mais facilmente notada para transferências pequenas. 


1.5.4 Necessidades de desempenho da aplicação 


A discussão nesta seção apresentou uma visão do desempenho centrada na rede; ou seja, falamos em 
termos do que um determinado enlace ou canal admitirá. A suposição implícita foi que os aplicativos 
possuem necessidades simples — eles querem o máximo de largura de banda que a rede puder oferecer. 
Isso certamente é verdade para o programa de biblioteca digital que mencionamos anteriormente, que 
está transmitindo uma imagem de 25 MB; quanto mais largura de banda disponível, mais rapidamente 
o programa poderá retornar a imagem ao usuário. 

Entretanto, algumas aplicações são capazes de indicar um limite superior sobre quanta largura de 
banda elas precisam. As aplicações de vídeo são um exemplo importante. Suponha que alguém queira 
enviar um fluxo de vídeo que tenha um quarto do tamanho de uma tela de TV padrão; ou seja, ele tem 
uma resolução de 352 por 240 pixels. Se cada pixel for representado por 24 bits de informação, como é 
o caso para cores de 24 bits, então o tamanho de cada quadro seria 


(352 x 240 x 24)/8 = 247,5 KB 


Se a aplicação precisa suportar uma taxa de quadros de 30 quadros por segundo, então ela poderia 
solicitar uma vazão de 75 Mbps. A capacidade da rede de oferecer mais largura de banda não interessa 
para tal aplicação, pois ela só tem essa quantidade de dados a transmitir em um dado intervalo de 
tempo. 

Infelizmente, a situação não é tão simples quanto este exemplo sugere. Devido à diferença entre dois 
quadros adjacentes quaisquer em um fluxo de vídeo normalmente ser pequena, é possível compactar 
o vídeo transmitindo apenas as diferenças entre quadros adjacentes. Cada quadro também pode ser 
compactado porque nem todos os detalhes em uma imagem são prontamente percebidos pelo olho 
humano. O vídeo compactado não flui em uma velocidade constante, mas varia com o tempo de acordo 
com fatores como a quantidade de movimentos e detalhes na imagem e o algoritmo de compactação 
sendo usado. Portanto, é possível dizer qual será o requisito médio de largura de banda, mas a taxa ins- 
tantânea pode ser maior ou menor. 

A questão principal é o intervalo de tempo sobre o qual a média é calculada. Suponha que os dados 
deste exemplo de aplicação de vídeo possam ser compactados até o ponto em que a aplicação precise 
de apenas 2 Mbps, em média. Se ela transmitir 1 megabit em um intervalo de 1 segundo e 3 megabits no 
próximo intervalo de 1 segundo, então pelo intervalo de 2 segundos ela está transmitindo em uma taxa 
média de 2 Mbps; porém, isso será de pouco consolo para um canal que foi projetado para dar suporte 
a não mais do que 2 megabits em qualquer segundo. Claramente, apenas conhecer as necessidades de 
largura de banda média de uma aplicação nem sempre será suficiente. 

Entretanto, em geral, é possível colocar um limite superior sobre o tamanho de uma rajada que uma 
aplicação como essa provavelmente transmitirá. Uma rajada poderia ser descrita por alguma taxa de 
pico que é mantida por algum período de tempo. Como alternativa, ela poderia ser descrita como o 
número de bytes que podem ser enviados na taxa de pico antes de retornar à taxa média ou alguma 
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FIGURA 1.20 Jitter induzido pela rede. 


taxa inferior. Se essa taxa de pico for maior do que a capacidade disponível no canal, então os dados em 
excesso terão que ser armazenados em algum buffer em algum ponto, para serem transmitidos mais 
tarde. Saber o tamanho máximo de uma rajada que poderia ser enviada permite que o projetista de rede 
aloque capacidade de buffer suficiente para armazenar a rajada. Voltaremos ao assunto de descrever o 
tráfego de rajada com precisão no Capítulo 6. 

Semelhante ao modo como as necessidades de largura de banda de uma aplicação podem ser algo 
diferente de “o quanto for possível”, os requisitos de atraso de uma aplicação podem ser mais complexos 
do que simplesmente “o mínimo de atraso possível”. No caso do atraso, às vezes não importa tanto se 
a latência de ida da rede é 100 ms ou 500 ms, mas sim se a latência varia de um pacote para outro. A 
variação na latência é chamada de jitter. 

Considere a situação em que a origem envia um pacote uma vez a cada 33 ms, como aconteceria para 
uma aplicação de vídeo transmitindo quadros 30 vezes por segundo. Se os pacotes chegarem no destino 
espaçados exatamente por 33 ms, então podemos deduzir que o atraso experimentado por cada pacote 
na rede foi exatamente igual. Porém, se o espaçamento entre os instantes em que os pacotes chegam ao 
destino — às vezes chamado de lacuna entre pacotes — for variável, então o atraso experimentado pela 
sequência de pacotes também deve ter sido variável, e considera-se que a rede introduziu jitter no fluxo 
de pacotes, como mostra a Figura 1.20. Essa variação geralmente não é introduzida em um único enlace 
físico, mas pode acontecer quando os pacotes experimentam diferentes atrasos de enfileiramento em 
uma rede de comutação de pacotes com múltiplos saltos. Esse atraso de enfileiramento corresponde 
ao componente de Fila da latência, definido anteriormente nesta seção, que varia com o tempo. 

Para entender a relevância do jitter, suponha que os pacotes sendo transmitidos pela rede conte- 
nham quadros de vídeo e, para exibir esses quadros na tela, o receptor precisa receber um novo quadro 
a cada 33 ms. Se um quadro chega adiantado, então ele pode simplesmente ser salvo pelo receptor até 
que seja o momento de exibi-lo. Infelizmente, se um quadro chega atrasado, então o receptor não terá 
o quadro de que precisa no momento de atualizar a tela, e a qualidade do vídeo será negativamente 
afetada; ele não será uniforme. Observe que não é estritamente necessário eliminar o jitter, mas apenas 
saber o quão ruim ele está. O motivo para isso é que, se o receptor souber os limites superior e inferior 
de latência que um pacote pode experimentar, ele pode adiar o momento em que começa a reproduzir 
o vídeo (ou seja, exibir o primeiro quadro) por tempo suficiente para garantir que, no futuro, ele sempre 
terá um quadro para exibir quando for preciso. O receptor atrasa o quadro, efetivamente suavizando o 
jitter, armazenando-o em um buffer. Retornaremos ao assunto do jitter no Capítulo 9. 


1.6 Resumo 


As redes de computadores, e particularmente a Internet, experimentaram um crescimento enorme 
durante os últimos 30 anos, e agora podem oferecer uma grande variedade de serviços, desde realizar 
negócios até fornecer acesso a entretenimento e permitir a criação de redes sociais. Grande parte desse 
crescimento pode ser atribuído à natureza de uso geral das redes de computadores e, em particular, à 
capacidade de acrescentar novas funcionalidades à rede criando-se software que pode ser executado 
em computadores de baixo custo e alto desempenho. Com isso em mente, o objetivo primordial deste 
livro é descrever as redes de computadores de modo que, quando você terminar de lê-lo, sinta que, 
se tivesse um exército de programadores à sua disposição, realmente poderia construir uma rede de 
computadores totalmente funcional a partir do zero. Este capítulo estabelece a base para a realização 
desse objetivo. 
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O primeiro passo que demos em direção a esse objetivo foi identificar cuidadosamente o que espe- 
ramos de uma rede. Por exemplo, uma rede precisa, primeiro, oferecer conectividade a baixo custo e de 
forma escalável entre um conjunto de computadores. Isso é feito por meio da interconexão aninhada 
de nós e enlaces, e compartilhando-se essa base de hardware por meio do uso de multiplexação 
estatística. Isso resulta em uma rede de comutação de pacotes, em cima da qual definimos então uma 
coleção de serviços de comunicação processo a processo. 

O segundo passo é definir uma arquitetura em camadas que servirá como um modelo para o nosso 
projeto. Os objetos centrais dessa arquitetura são os protocolos de rede. Os protocolos fornecem um 
serviço de comunicação aos protocolos de nível mais alto e definem a forma e o significado das men- 
sagens trocadas com seus pares executando em outras máquinas. Analisamos rapidamente duas das 
arquiteturas mais utilizadas: a arquitetura OSI de sete camadas e a arquitetura Internet. Este livro segue 
mais de perto a arquitetura Internet, tanto em sua organização quanto como uma fonte de exemplos. 

O terceiro passo é implementar os protocolos e aplicativos de rede, normalmente em software. 
Tanto protocolos como aplicações precisam de uma interface pela qual invocam os serviços de outros 
protocolos no subsistema de rede. A interface de sockets é a interface mais utilizada entre os aplicativos 
e o subsistema de rede, mas uma interface ligeiramente diferente em geral é usada dentro do subsistema 
de rede. 

Finalmente, a rede como um todo precisa oferecer alto desempenho, sendo que as duas medidas 
de desempenho em que estamos mais interessados são latência e vazão. Conforme veremos em ou- 
tros capítulos, é o produto dessas duas medidas — o chamado produto atraso x largura de banda — que 
normalmente desempenha um papel crítico no projeto do protocolo. 


E E O que vem em seguida: Computação em nuvem E 


É evidente que as redes de computadores se tornaram uma parte integral das vidas cotidianas 
de inúmeras pessoas. O que começou há mais de 40 anos como sistemas experimentais, como a 
ARPANET - conectando computadores de grande porte por linhas telefônicas de longa distância —, 
transformou-se em uma parte dominante de nossas vidas. Isso também se tornou um grande 
negócio, e onde há um grande negócio existem muitos interessados. Nesse caso, temos a indústria 
de computação, que se envolveu cada vez mais na integração da computação e da comunicação; as 
operadoras de telefone e cabo, que reconhecem o mercado para transportar todos os tipos de dados, 
não apenas voz e televisão; e, talvez mais importante, os muitos empreendedores criando novas 
aplicações e serviços baseados na Internet, como voz sobre IP (Voice over IP — VOIP), jogos online, 
mundos virtuais, serviços de buscas, hospedagem de conteúdos, comércio eletrônico e assim por 
diante. Vale a pena mencionar que um dos maiores nomes de hoje na “computação em nuvem”, a 
Amazon.com, conseguiu essa posição primeiramente adotando tecnologias da Internet para vender 
produtos de consumo, como livros, e depois tornando sua infraestrutura de computação disponível 
a outros como um serviço sobre a rede. 

Há alguns anos, um objetivo razoável para a criação de redes pode ter sido fornecer acesso à rede 
a cada residência, mas, pelo menos nos países desenvolvidos, esse processo já está distante. Acesso 
ubíquo (ou onipresente) à rede atualmente inclui obter acesso de qualquer lugar, incluindo aviões 
e trens, e em uma gama cada vez maior de dispositivos. Embora a Internet em grande parte tenha 
evoluído em uma era de mainframe fixo e depois de computadores pessoais, hoje em dia o conjunto 
de dispositivos a serem conectados inclui telefones móveis e até mesmo dispositivos menores, 
como sensores (que também poderiam ser móveis). Assim, parece claro que a Internet terá que 
continuar sua escalada para prover suporte a um número ordens de grandeza maior do que o atual 
e que muitos desses dispositivos serão móveis, talvez conectados intermitentemente por enlaces 
sem fios de qualidade altamente variável. Ao mesmo tempo, esses dispositivos serão conectados a 
centros de dados maiores — contendo dezenas de milhares de processadores e muitos petabytes de 
armazenamento —, que armazenarão e analisarão os dados sendo gerados, tudo com a esperança 
de permitir a criação de aplicações ainda mais poderosas, que nos ajudem a navegar por nossas 
vidas cotidianas. E os dispositivos que carregamos normalmente são apenas um meio de acessar “a 
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nuvem” — o conjunto amorfo de máquinas que armazenam e processam nossos documentos, fotos, 
dados, redes sociais etc., que esperamos poder acessar de qualquer lugar onde estivermos. 
As previsões sobre o futuro das redes tendem a parecer tolas alguns anos após serem feitas (muitas 
previsões notórias sobre um desastre iminente da Internet, por exemplo, não se concretizaram). 
O que podemos dizer com confiança é que ainda restam muitos desafios técnicos — questões de 
conectividade, facilidade de gerenciamento, escalabilidade, usabilidade, desempenho, confiabilidade, 
segurança, justiça, efetividade de custo, etc. — que se interpõem entre o estado da arte e o tipo de 
rede global, onipresente e heterogênea que muitos acreditam ser iminente. Em outras palavras, o 
campo das redes está bastante vivo, com problemas interessantes ainda a serem solucionados, e 
esses problemas e as ferramentas para resolvê-los são o foco deste livro. 


Leitura adicional 


Redes de computadores não são a primeira tecnologia orientada a comunicações a ter aberto caminho no cotidiano da 
nossa sociedade. Por exemplo, a primeira parte do século XX assistiu a introdução do telefone e depois, durante a década 
de 1950, a televisão passou a ser utilizada de forma generalizada. Ao considerar o futuro das redes — o quão ampla será 
sua expansão e como a utilizaremos -, é instrutivo estudar essa história. Nossa primeira referência é um bom ponto de 
partida para fazer isso (a publicação inteira é dedicada aos primeiros 100 anos das telecomunicações). 

A segunda referência é considerada um dos artigos embrionários sobre a arquitetura da Internet. Os dois artigos finais não 
são específicamente voltados a redes, mas apresentam pontos de vista que capturam a “abordagem de sistemas” deste 
livro. O artigo de Saltzer (indicado a seguir) e outros motivam e descrevem uma das regras mais aplicadas da arquitetura 
de rede — o argumento fim a fim- que continua a ser amplamente citado nos dias atuais. O artigo de Mashey descreve o 
raciocínio por trás das arquiteturas RISC (Reduced Instruction Set Computer); como descobriremos em breve, fazer boas 
escolhas sobre onde colocar funcionalidades em um sistema complexo é o princípio maior do projeto de sistemas. 


Pierce, J. Telephony - a personal view. IEEE Communications, v. 22, n. 5, p. 116-20, maio de 1984. 

Clark, D. The design philosophy of the DARPA Internet protocols. Proceedings of the SIGCOMM '88 Symposium, p. 106-14, 
agosto de 1988. 

Saltzer, J.; Reed, D.; Clark, D. End-to-end arguments in system design. ACM Transactions on Computer Systems, v. 2, n. 4, 
p. 277-88, novembro de 1984. 

Mashey, J. RISC, MIPS, and the motion of complexity. UniForum 1986 Conference Proceedings, p. 116-24, fevereiro de 
1986. 


Vários textos oferecem uma introdução às redes de computadores: Stallings apresenta um tratamento 
enciclopédico do assunto, com ênfase nos níveis mais baixos da hierarquia OSI [Sta07]; Comer apresenta 
uma boa introdução à arquitetura Internet [Com05]. 

Para colocar as redes de computadores em um contexto mais amplo, dois livros — um tratando do 
passado e o outro olhando para o futuro - são leituras essenciais. O primeiro é The Early History of Data 
Networks [HP95] de Holzmann e Pehrson. É surpreendente como muitas ideias abordadas no livro 
que você está lendo foram inventadas durante os anos 1700. O segundo é Realizing the Information 
Future: The Internet and Beyond, um livro preparado pelo Comitê de Telecomunicações e Ciência da 
Computação (Computer Science and Telecommunications Board) do Conselho Nacional de Pesquisa 
(National Research Council) [NRC94]. 

Neste livro, tentamos trazer uma abordagem de sistemas à área das redes de computadores. Reco- 
mendamos o tratamento geral dos sistemas de computação por Saltzer e Kaashoek [SK09], que ensina 
muitos princípios importantes que se aplicam às redes e também a outros sistemas. Os sistemas ope- 
racionais em particular são importantes para muitos aspectos das redes; Tanenbaum [Tan07] oferece 
uma introdução aos conceitos de SO. 

Para acompanhar a história da Internet desde o seu início, o leitor deverá examinar a série de docu- 
mentos do tipo RFC (Request for Comments, ou Pedido de Comentários) da Internet. Esses documentos, 
que incluem de tudo, desde a especificação do TCP até piadas de Primeiro de Abril, podem ser obtidos 
em http://www ietf.org/rfc.html. Por exemplo, as especificações de protocolo para TCP UDP e IP estão 
disponíveis nas RFCs 793, 768 e 791, respectivamente. 

Para apreciar melhor a filosofia e a cultura da Internet, duas referências são recomendadas; ambas 
também são muito divertidas. Padlipsky oferece uma boa descrição dos seus primórdios, incluindo uma 
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comparação expositiva das arquiteturas Internet e OSI [Pad85]. Para obter um relato do que realmente 
acontece nos bastidores da IETF (Internet Engineering Task Force, ou Força-Tarefa de Engenharia da 
Internet), recomendamos o artigo de Boorsook [Boo95]. 

Há uma vastidão de artigos discutindo diversos aspectos das implementações de protocolo. Um bom 
ponto de partida é entender dois ambientes de implementação de protocolo completos: o mecanismo 
Stream do System V Unix [Rit84] e o x-kernel [HP91]. Além disso, [LMKQ89] e [SW95] descrevem a im- 
plementação do TCP/IP bastante utilizada no Berkeley Unix. 

De um modo mais geral, um grande conjunto de trabalhos trata da questão de estruturar e otimizar as 
implementações de protocolos. Clark foi um dos primeiros a discutir a relação entre o projeto modular 
e o desempenho de protocolos [Cla82]. Outros artigos introduziram depois disso o uso de upcalls” 
na estruturação de códigos de protocolo [Cla85] e o estudo dos overheads? de processamento no TCP 
[CJRS89]. Finalmente, [WM87] descreve como ganhar eficiência por meio de escolhas apropriadas de 
projeto e implementação. 

Vários artigos introduziram técnicas e mecanismos específicos que podem ser usados para melhorar 
o desempenho de protocolos. Por exemplo, [HMPT89] descreve alguns dos mecanismos usados no 
ambiente x-kernel, enquanto [MD93], [VL87] e [DP93] apresentam uma série de técnicas para melhorar 
o desempenho de protocolos. Além disso, o desempenho de protocolos executados em processadores 
paralelos — o bloqueio é uma questão básica nesses ambientes — é discutido em [BG93] e [NYKT94]. 

Finalmente, concluímos a seção de Leitura Adicional de cada capítulo com um conjunto de refe- 
rências “vivas”, URLs para locais na World Wide Web onde você pode aprender mais sobre os assuntos 
discutidos no capítulo. Como essas referências são vivas, é possível que elas não permaneçam ativas por 
um período de tempo indefinido. Por esse motivo, limitamos o conjunto de referências vivas no final 
de cada capítulo a sites que proveem software, fornecem um serviço ou relatam sobre as atividades em 
andamento de um grupo de trabalho ou agência de padronização. Em outras palavras, só indicamos 
URLs para o tipo de material que não pode ser facilmente referenciado usando citações padrão. Para 
este capítulo, incluímos três referências vivas: 


e http:/mkp.com/computer-networks: informações sobre este livro, incluindo suplementos, anexos 
e outros. 

e  http://www.ietf.org/: informações sobre a IETE seus grupos de trabalho, padrões etc. 

e http://dblp.uni-trier.de/db/index.html: uma bibliografia de artigos de pesquisa em ciência 
da computação dotada de mecanismos de busca. 


Exercícios 


1. Use o FTP anônimo para se conectar a ftp.rfc-editor.org (diretório in-notes), e obtenha o índice do 
REC. Além disso, obtenha as especificações de protocolo para o TCP o IP e o UDP 

2. O utilitário whois do Unix pode ser usado para determinar o nome de domínio correspondente 
a uma organização, ou vice-versa. Leia a documentação da página obtida via comando man 
para o whois e faça experimentos com ele. Execute whois princeton.edu e whois princeton, 
para iniciar. Alternativamente, explore a interface do whois no endereço http://www .internic.net/ 
whois.html. 

3. Calcule o tempo total exigido para transferir um arquivo de 1.000 KB nos seguintes casos, 
considerando um RTT de 50 ms, um tamanho de pacote de 1 KB de dados e 2 RTTs iniciais 
para o estabelecimento da conexão (handshaking) antes que os dados sejam enviados: 
a. A largura de banda é de 1,5 Mbps e os pacotes de dados podem ser enviados continuamente. 
b. A largura de banda é de 1,5 Mbps, mas depois que terminarmos de enviar cada pacote 

de dados, devemos esperar um RTT antes de enviar o pacote seguinte. 


"Uma upcall é um tipo de “intervenção” (por exemplo, uma chamada de uma operação) de uma camada mais interna (o 
núcleo) no código de uma camada superior.(N.T.) 

“Dá-se o nome de overhead a qualquer carga computacional adicional introduzida por um mecanismo (por exemplo, 
expansão do tamanho dos pacotes devido à adição de um cabeçalho aos mesmo, aumento no tempo de envio devido ao 
processamento dos dados etc.) (N.T.) 
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c. Alargura de banda é “infinita”, significando que consideramos o tempo de transmissão como 
zero e que até 20 pacotes podem ser enviados por RTT. 

d. A largura de banda é infinita e, durante o primeiro RTT, podemos enviar um pacote (21-1), 
durante o segundo RTT podemos enviar dois pacotes (22-l), durante o terceiro podemos 
enviar quatro (2%!) e assim por diante. (Uma justificativa para esse aumento exponencial será 
dada no Capítulo 6.) 

Calcule o tempo total necessário para transferir um arquivo de 1,5 MB nos seguintes casos, 

considerando um RTT de 80 ms, um tamanho de pacote de 1 KB de dados e 2 RTTs iniciais para o 

estabelecimento da conexão (handshaking) antes que os dados sejam enviados: 

a. A largura de banda é de 10 Mbps e os pacotes de dados podem ser enviados 
continuamente. 

b. A largura de banda é de 10 Mbps, mas depois que terminarmos de enviar cada pacote 
de dados, devemos esperar um RTT antes de enviar o pacote seguinte. 

c. O enlace permite uma transmissão infinitamente rápida, mas limita a largura de banda 
de modo que somente 20 pacotes possam ser enviados por RTT. 

d. O tempo de transmissão é zero, como no item (c), mas durante o primeiro RTT podemos 
enviar um pacote, durante o segundo RTT podemos enviar dois pacotes, durante o terceiro 
podemos enviar quatro (2%!) etc. (Uma justificativa para esse aumento exponencial será dada 
no Capítulo 6.) 

Considere um enlace ponto a ponto de 4 km de comprimento. Em qual largura de banda o 

atraso de propagação (na velocidade de 2 x 10ºm/s) igualaria o atraso de transmissão para 

pacotes de 100 bytes? E com pacotes de 512 bytes? 


. Considere um enlace ponto a ponto de 50 km de comprimento. Em qual largura de banda 


o atraso de propagação (em uma velocidade de 2 x 10m/s) é igual ao atraso de transmissão 

para pacotes de 100 bytes? E para pacotes de 512 bytes? 

Que propriedades dos endereços postais provavelmente seriam compartilhadas por 

um esquema de endereçamento de rede? Que diferenças você esperaria encontrar? Que 

propriedades da numeração de telefone poderiam ser compartilhadas por um esquema 

de endereçamento de rede? 

Uma propriedade dos endereços é que eles são exclusivos; se dois nós tivessem o mesmo 

endereço, seria impossível distinguir entre eles. Que outras propriedades poderiam ser úteis para 

os endereços de rede? Você consegue imaginar algumas situações em que os endereços de rede 

(ou postais ou de telefone) poderiam não ser exclusivos? 

Dê um exemplo de uma situação em que os endereços de multicast poderiam ser benéficos. 

Que diferenças em termos de modelos de tráfego fazem com que a STDM seja uma forma 

econômica de multiplexação para uma rede de telefonia de voz, assim como a FDM é uma forma 

econômica de multiplexação para redes de televisão e rádio, porém ambas sejam rejeitadas 

como não sendo econômicas para uma rede de computadores de propósito geral? 

Qual é o “comprimento” de um bit em um enlace de 10 Gbps? Qual é o comprimento 

de um bit em um fio de cobre, no qual a velocidade de propagação é de 2,3 x 108 m/s? 

Quanto tempo é necessário para transmitir x KB por um enlace de y Mbps? Dê a sua resposta em 

função de x e y. 

Suponha que um enlace ponto a ponto de 1 Gbps esteja sendo estabelecido entre a Terra e 

uma nova colônia lunar. A distância da Lua à Terra é de aproximadamente 385.000 km, e os dados 

trafegam pelo enlace na velocidade da luz (3 x 108m/s). 

a. Calcule o RTT mínimo para o enlace. 

b. Usando o RTT como o atraso, calcule o produto atraso x largura de banda do enlace. 

c. Qual é o significado do produto atraso x largura de banda calculado em (b)? 

d. Uma câmera na base lunar tira fotos da Terra e as salva em formato digital em disco. Suponha 
que o Controle da Missão na Terra queira obter a imagem mais atual, que tem 25 MB. Qual 
é a quantidade mínima de tempo decorrido entre a solicitação dos dados ser enviada e o 
término da transferência? 
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Suponha que um enlace ponto a ponto de 128 kbps seja estabelecido entre a Terra e um 
carro-robô em Marte. A distância da Terra a Marte (quando eles estão mais próximos) é de 
aproximadamente 55 Gm, e os dados trafegam pelo enlace na velocidade da luz (3 x 108m/s). 

a. Calcule o RTT mínimo para o enlace. 

b. Calcule o produto atraso x largura de banda para o enlace. 

c. Uma câmera no carro-robô tira fotos dos seus arredores e as envia à Terra. Em quanto tempo, 
depois de a foto ser tirada, ela chega ao Controle da Missão na Terra? Considere que cada 
imagem tenha um tamanho de 5 Mb. 

Para cada uma das seguintes operações em um servidor de arquivos remoto, discuta se elas são 

mais prováveis de serem sensíveis ao atraso ou sensíveis à largura de banda: 

a. Abrir um arquivo. 

b. Ler o conteúdo de um arquivo. 

c. Listar o conteúdo de um diretório. 

d. Exibir os atributos de um arquivo. 

Calcule a latência (do primeiro bit enviado até o último bit recebido) nos seguintes cenários: 

a. Uma rede Ethernet de 100 Mbps com um único switch do tipo armazenar e encaminhar 
(store-and-forward) no caminho e um pacote com tamanho de 12.000 bits. Suponha que cada 
enlace introduza um atraso de propagação de 10 ms e que o switch comece a retransmitir 
imediatamente após ter acabado de receber o pacote. 

b. Uma rede igual à do item (a), mas com três switches. 

c. Uma rede igual à do item (a), mas suponha que o switch implemente a comutação do tipo 
“cut-through”; ele é capaz de começar a retransmitir o pacote após os 200 primeiros bits 
terem sido recebidos. 

Calcule a latência (do primeiro bit enviado até o último bit recebido) nos seguintes cenários: 

a. Uma rede Ethernet de 1 Gbps com um único switch do tipo armazenar e encaminhar 
(store-and-forward) no caminho e um pacote com tamanho de 5.000 bits. Suponha que cada 
enlace introduza um atraso de propagação de 10 ms e que o switch comece a retransmitir 
imediatamente após ter acabado de receber o pacote. 

b. Uma rede igual à do item (a), mas com três switches. 

c. Uma rede igual à do item (b), mas suponha que o switch implemente a comutação do tipo 
“cut-through”; ele é capaz de começar a retransmitir o pacote após os 128 primeiros bits 
terem sido recebidos. 

Calcule a largura de banda efetiva para os seguintes casos. Para os itens (a) e (b), suponha que haja 

uma fonte que envia dados constantemente; para o item (c), basta calcular a média por 12 horas. 

a. Uma rede Ethernet de 100 Mbps composta por três switches do tipo armazenar-e-encaminhar 
(store-and-forward), como no Exercício 16(b). Os Switches podem enviar dados por um enlace 
enquanto recebem dados em outro. 

b. Uma rede igual à do item (a), mas com o emissor tendo que esperar um pacote de 
confirmação de 50 bytes depois de enviar cada pacote de dados de 12.000 bits. 

c. Um cenário de entrega noturna (12 horas) de 100 DVDs contendo 4,7 GB cada. 

Calcule o produto atraso x largura de banda para os seguintes enlaces. Use o atraso de ida, 

medido do primeiro bit enviado até o primeiro bit recebido. 

a. Uma rede Ethernet de 100 Mbps com um atraso de 10 ms. 

b. Uma rede Ethernet de 100 Mbps com um único switch do tipo armazenar e encaminhar 
(store-and-forward) do Exercício 16(b), um tamanho de pacote de 12.000 bits e 10 ms 
de atraso de propagação por enlace. 

c. Um enlace T1 de 1,5 Mbps, com um atraso transcontinental de ida de 50 ms. 

d. Um enlace T1 de 1,5 Mbps entre duas estações terrestres comunicando-se através de um 
satélite em órbita geoestacionária a 35.900 km de altura. O único atraso é o atraso 
de propagação na velocidade da luz da Terra até o satélite e de volta. 

Os hosts A e B são conectados, cada um, a um switch S por meio de enlaces de 100 Mbps, 

como na Figura 1.21. O atraso de propagação em cada enlace é de 20 us. S é um dispositivo 
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URA 1.21 Diagrama para o Exercício 20. 


do tipo armazenar e encaminhar (store-and-forward); ele começa a retransmitir um pacote 

recebido 35 ps após ter acabado de recebê-lo. Calcule o tempo total necessário para transmitir 

10.000 bits de A para B 

a. na forma de um único pacote. 

b. na forma de dois pacotes de 5.000 bits que são enviados um após o outro. 

Suponha que um host tenha um arquivo de 1 MB que deve ser enviado para outro host. 

O arquivo pode ser 50% compactado se for utilizado 1 segundo de tempo da CPU, ou pode ser 

60% compactado se forem utilizados 2 segundos. 

a. Calcule a largura de banda para a qual ambas as opções de compactação levam ao mesmo 
tempo total para a compactação + transmissão. 

b. Explique por que a latência não afeta a sua resposta. 

Suponha que certo protocolo de comunicações envolva uma expansão de tamanho (overhead) 

de 50 bytes por pacote, para cabeçalhos e enquadramento. Enviamos 1 milhão de bytes de 

dados usando esse protocolo; porém, um byte de dados é corrompido e o pacote inteiro que 

o transporta é então descartado. Calcule o número total de bytes de overhead + descarte para 

tamanhos de pacote de dados de de 100, 10.000 e 20.000 bytes. Qual é o tamanho ideal? 

Suponha que você queira transferir um arquivo de n bytes por um caminho composto de origem, 

destino, 7 enlaces ponto a ponto e 5 switches. Suponha que cada enlace tenha um atraso de 

propagação de 2 ms e uma largura de banda de 4 Mbps, e que os switches admitam comutação 

de circuitos e de pacotes. Assim, você pode quebrar o arquivo em pacotes de 1 KB ou montar 

um circuito pelos switches e enviar o arquivo como um fluxo de bits contíguos. Suponha que 

os pacotes tenham 24 bytes de informação de cabeçalho e 1.000 bytes de carga útil (payload), 

que o processamento de pacotes do tipo armazenar e encaminhar (store-and-forward) em cada 

switch incorra em um atraso de 1 ms após o pacote ter sido completamente recebido, que os 

pacotes podem ser enviados continuamente sem esperar confirmações e que a configuração do 

circuito exija que uma mensagem de 1 KB percorra um caminho de ida e volta, incorrendo em 

um atraso de 1 ms em cada switch após a mensagem ter sido completamente recebida. Suponha 

que os switches não introduzam atraso nos dados atravessando um circuito. Você também pode 

considerar que o tamanho do arquivo é um múltiplo de 1.000 bytes. 

a. Para que tamanho de arquivo de n bytes o número total de bytes enviados pela rede é menor 
para circuitos do que para pacotes? 

b. Para que tamanho de arquivo de n bytes a latência total resultante antes que o arquivo inteiro 
chegue ao destino é menor para circuitos do que para pacotes? 

c. Qual é a sensibilidade desses resultados ao número de switches ao longo do caminho? E à largura 
de banda dos enlaces? E à razão entre o tamanho do pacote e o tamanho do cabeçalho do pacote? 

d. O quão preciso você acredita que esse modelo seja com relação aos méritos da comutação de 
circuitos e de pacotes? Ele ignora considerações importantes que discreditem uma ou outra 
técnica? Em caso positivo, quais são elas? 

Considere uma rede com uma topologia em anel,º larguras de banda de 100 Mbps e velocidade 

de propagação de 2 x 10ºm/s. Qual seria exatamente a circunferência do anel para que ele 

contenha exatamente um pacote de 1.500 bytes, supondo que os nós não introduzam atraso? 

Qual seria a circunferência se houvesse um nó a cada 100 m, e cada nó introduzisse 10 us de 

atraso? 

Compare os requisitos de canal para o tráfego de voz com os requisitos para a transmissão em 

tempo real de música, em termos de largura de banda, atraso e jitter. O que teria que melhorar? 

Em aproximadamente quanto? Algum requisito de canal poderia ser relaxado? 


“Em uma topologia em anel, os hosts são conectados uns aos outros em sequência, formando um círculo fechado. (N.T.) 
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Para os itens seguintes, suponha que nenhuma compressão de dados seja feita, embora 

na prática isso quase nunca aconteça. Para os itens de (a) a (c), calcule a largura de banda 

necessária para transmitir em tempo real: 

a. Vídeo com uma resolução de 640 x 480, 3 bytes/pixel, 30 quadros/segundo. 

b. Vídeo com uma resolução de 160 x 120, 1 byte/pixel, 5 quadros/segundo. 

c. Música em CD-ROM, considerando que um CD contenha 75 minutos de música e ocupe 
650 MB. 

d. Suponha que um fax transmita uma imagem em preto e branco de 8 x 10 polegadas em uma 
resolução de 72 pixels por polegada. Quanto tempo essa transmissão levaria usando um 
modem de 14,4 kbps? 

Para os seguintes itens, como no problema anterior, suponha que nenhuma compactação de 

dados seja feita. Calcule a largura de banda necessária para transmitir em tempo real: 

a. Vídeo de alta definição com uma resolução de 1920 x 1080, 24 bits/pixel, 30 quadros /segundo. 

b. Áudio de voz em POTS (serviço telefônico comum) com amostras de 8 bits a 8 KHz. 

c. Áudio de voz em telefone móvel GSM com amostras de 260 bits a 50 Hz. 

d. Áudio de alta definição HDCD com amostras de 24 bits a 88,2 kHz. 

Discuta as necessidades de desempenho relativo das seguintes aplicações em termos de largura 

de banda média, largura de banda de pico, latência, jitter e tolerância a perdas: 

Servidor de arquivos. 

Servidor de impressão. 

Biblioteca digital. 

Monitoramento rotineiro de instrumentos para medição de clima em ambientes remotos. 

Voz. 

Monitoramento de vídeo em uma sala de espera. 

g. Transmissão de televisão. 

Suponha que um meio compartilhado M ofereça aos hosts A;, As, ..., Ay a oportunidade para 

transmitir um pacote, na forma de um rodízio (escalonamento round-robin); os hosts que não 

têm dados para enviar imediatamente abrem mão de M. Como isso difere da STDM? Como se 
compara esse esquema com a STDM em termos de utilização de rede? 

Considere um protocolo simples para transferir arquivos por um enlace. Após uma negociação 

inicial, A envia pacotes de dados com tamanho de 1 KB para B; B, então, responde com uma 

confirmação, um pacote conhecido como acknowledgement, ou ACK. A sempre espera por cada 

ACK antes de enviar o próximo pacote de dados; isso é conhecido como stop-and-wait, ou parar 

e esperar. Os pacotes que se atrasam são considerados perdidos, sendo então retransmitidos. 

a. Na ausência de quaisquer perdas ou duplicações de pacotes, explique por que não é 
necessário incluir quaisquer dados de “número de sequência” nos cabeçalhos dos pacotes, 

e mesmo assim o destino será capaz de determinar a sequência correta dos mesmos. 

b. Suponha que o enlace possa perder pacotes ocasionalmente, mas que os pacotes que chegam 
sempre chegam na ordem enviada. Um número de sequência de 2 bits (ou seja, N mod 4) 

é suficiente para A e B detectarem e enviarem quaisquer pacotes perdidos? Um número 
de sequência de 1 bit é suficiente? 

c. Agora suponha que o enlace possa fornecer dados fora de ordem e que às vezes um pacote 
pode ser entregue até 1 minuto após os pacotes subsequentes. Como isso mudaria os 
requisitos do número de sequência? 

Suponha que os hosts A e B estejam conectados por um enlace. O host A transmite 

continuamente a hora atual fornecida por um relógio de alta precisão, a uma taxa regular, com 

uma velocidade alta o suficiente para consumir toda a largura de banda disponível. O host B lê 
esses valores de tempo e os grava, associando cada um deles à hora indicada em seu próprio 
relógio local, que está sincronizado com o relógio de A. Mostre exemplos qualitativos da saída 
de B supondo que o enlace tenha 

a. Alta largura de banda, alta latência, baixo jitter. 

b. Baixa largura de banda, alta latência, alto jitter. 
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c. Alta largura de banda, baixa latência, baixo jitter, perda de dados ocasional. 

Por exemplo, um enlace com zero jitter, uma largura de banda alta o suficiente para gravar 

a cada dois pulsos de relógio e uma latência de 1 pulso poderia gerar algo como (0000,0001), 

(0002,0003), (0004,0005). 
Obtenha e construa o programa de exemplo usando sockets denominado simplex-talk, mostrado 
no texto. Inicie um servidor e um cliente, em janelas separadas. Enquanto o primeiro cliente 
estiver sendo executado, inicie 10 outros clientes que se conectam ao mesmo servidor; esses 
outros clientes provavelmente deverão ser iniciados em segundo plano, com sua entrada 
redirecionada para um arquivo. O que acontece com esses 10 clientes? Seus connect(s falham, 
esgotam o tempo limite ou têm sucesso? Alguma outra chamada é bloqueada? Agora encerre 
o primeiro cliente. O que acontece? Experimente isso também com o valor MAX PENDING 
do servidor definido como 1. 
Modifique o programa baseado em sockets denominado simplex-talk de modo que, toda vez que 
o cliente enviar uma linha ao servidor, este enviará a linha de volta ao cliente. O cliente 
(e o servidor) agora terá que fazer chamadas alternadas a recv() e send(). 
Modifique o programa baseado em sockets denominado socket simplex-talk de modo que ele 
use UDP como protocolo de transporte em vez de TCP Você terá que substituir o parâmetro 
SOCK STREAM pelo parâmetro SOCK DGRAM no cliente e no servidor. Depois, no servidor, 
remova as chamadas a listen() e accept() e substitua os dois laços aninhados no final por um 
único laço que invoca recv() com o socket s. Finalmente, veja o que acontece quando dois desses 
clientes UDP se conectam simultaneamente ao mesmo servidor UDP e compare isso com o 
comportamento do TCP 
Pesquise as diferentes opções e parâmetros que se pode definir para uma conexão TCP (Faça 
uma chamada a “man tcp” no Unix.) Experimente com diversas opções de parâmetro para ver 
como elas afetam o desempenho do TCP 
O utilitário ping do Unix pode ser usado para determinar o RTT de vários hosts da Internet. Leia 
a página de man para o ping (Faça uma chamada a “man ping” no Unix.) e use-a para descobrir 
o RTT para www.cs.princeton.edu em Nova Jersey e www.cisco.com na Califórnia. Meça os valores 
de RTT em diferentes horários do dia e compare os resultados. O que você imagina que sejam 
fatores responsáveis pelas diferenças? 
O utilitário traceroute do Unix, ou seu equivalente tracert do Windows, pode ser usado para 
determinar uma sequência de roteadores através dos quais uma mensagem é roteada. Use isso 
para determinar o caminho de onde você está para alguns sites web. O quanto o número de 
saltos se relaciona com os tempos de RTT do comando ping? O quanto o número de saltos se 
relaciona com a distância geográfica? 
Use traceroute, como antes, para mapear alguns dos roteadores dentro da sua organização 
(ou para verificar se nenhum é utilizado). 


Conectando-se 


É erro tentar prever o futuro muito distante. Só se pode lidar 
com um elo da cadeia do destino de cada vez. 
Winston Churchill 


No Capítulo 1, vimos que as redes consistem em enlaces que interconectam nós. Um dos problemas 
fundamentais que enfrentamos é como interconectar dois nós. Também apresentamos a abstração de 
“nuvem” para representar uma rede sem revelar todas as suas complexidades internas. Assim, também 
precisamos enfrentar o problema semelhante de conectar um host a uma nuvem. Esse, com efeito, é o 
problema que todo Provedor de Serviço de Internet enfrenta quando deseja conectar um novo cliente 
à rede: como conectar mais um nó à nuvem do provedor? 


E E Problema: conectando-se a uma rede E 


Se quisermos construir uma rede trivial de dois nós com um enlace ou conectar o bilionésimo host 
a uma rede existente, como a Internet, precisamos resolver um conjunto comum de problemas. 
Primeiro, precisamos de algum meio físico sobre o qual faremos a conexão. O meio pode ser uma 
extensão de fio, um trecho de fibra óptica ou algum meio menos tangível (como o ar) através do 
qual a radiação eletromagnética (por exemplo, ondas de rádio) pode ser transmitida. Ele pode 
cobrir uma área pequena (por exemplo, um prédio comercial) ou uma área muito grande (por 
exemplo, transcontinental). Contudo, a conexão de dois nós com um meio adequado é apenas o 
primeiro passo. Cinco outros problemas precisam ser enfrentados antes que os nós possam trocar 
pacotes com sucesso. 

O primeiro é codificar bits no meio de transmissão de modo que eles possam ser entendidos 
por um nó receptor. O segundo é a questão de delinear a sequência de bits transmitidos pelo 
enlace em mensagens completas que possam ser entregues ao nó final. Esse é o problema do 
enquadramento, e as mensagens entregues aos hosts finais normalmente são chamadas de 
quadros ou frames (ou, às vezes, pacotes). Terceiro, como os quadros às vezes são corrompidos 
durante a transmissão, é preciso detectar esses erros e tomar a ação apropriada; esse é o 
problema de detecção de erros. O quarto problema é fazer com que um enlace pareça confiável 
apesar do fato de corromper quadros de tempos em tempos. Finalmente, nos casos em que o 
enlace é compartilhado por vários hosts - como normalmente acontece com enlaces sem fios, 
por exemplo —, é preciso mediar o acesso a esse enlace. Esse é o problema do controle de acesso 
ao meio. 

Embora esses cinco problemas — codificação, enquadramento, detecção de erros, entrega 
confiável e mediação de acesso — possam ser discutidos de forma abstrata, eles são problemas 
muito reais, que são tratados de diferentes maneiras por diferentes tecnologias de rede. Este 
capítulo considera essas questões no contexto de três tecnologias de rede específicas: enlaces 
ponto a ponto, redes CSMA (Carrier Sense Multiple Access) (das quais Ethernet é o exemplo mais 
famoso) e redes sem fios (para as quais o 802.11 é o padrão mais conhecido).! O objetivo deste 
capítulo é, ao mesmo tempo, analisar as tecnologias de rede disponíveis e explorar esses cinco 
problemas fundamentais. Examinaremos o que é necessário para utilizar uma grande variedade 
de meios físicos e tecnologias de enlace diferentes como blocos básicos para a construção de 
redes robustas e escaláveis. 


'Estritamente falando, 802.11 refere-se a um conjunto de padrões. 
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Tecnologia de acesso (por exemplo, fibra, cabo, Wi-Fi, celular...) 
FIGURA 2.1 Uma visão da Internet do ponto de vista do usuário final. 


2.1 Perspectivas na conexão 


Como vimos no Capítulo 1, as redes são construídas a partir de duas classes de blocos construtivos do 
hardware: nós e enlaces. Neste capítulo, vamos verificar o que é preciso para criar um enlace útil, de 
modo que redes grandes e confiáveis, contendo milhões de enlaces, possam ser constuídas. 

Embora os operadores de grandes redes lidem com enlaces que se espalham por centenas ou milhares 
de quilômetros conectando roteadores do tamanho de um refrigerador, o usuário típico de uma rede 
depara-se com enlaces principalmente como um meio de conectar um computador à Internet global. 
Às vezes, esse enlace é um enlace sem fio (Wi-Fi) em um local público; às vezes, é um enlace Ethernet 
em um prédio de escritórios ou em uma universidade; para uma fatia cada vez maior (e afortunada) da 
população, é um enlace de fibra óptica fornecido por uma companhia de telecomunicações ou provedor 
de serviços; e muitos outros utilizam algum tipo de fio de cobre ou cabo para a conexão. Felizmente, 
existem muitas estratégias comuns usadas nesses tipos aparentemente divergentes, de modo que 
todos eles podem se mostrar confiáveis e úteis para camadas mais altas da pilha de protocolos. Este 
capítulo examinará essas estratégias. 

A Figura 2.1 ilustra diversos tipos de enlaces conforme eles são vistos por um usuário final típico da 
Internet atual. No lado esquerdo, vemos uma série de dispositivos de usuários finais, variando desde 
telefones móveis a PDAs e computadores completos conectados de diversas formas a um ISP (Internet 
Service Provider, ou Provedor de Serviços de Internet). Embora esses enlaces possam ser de qualquer tipo 
mencionado anteriormente, ou algum outro tipo, todos eles têm a mesma aparência nessa figura - uma 
linha reta conectando um dispositivo a um roteador. Além disso, existem alguns enlaces que conectam 
roteadores dentro do ISP e um enlace que conecta o ISP ao “restante da Internet”, que consiste em muitos 
outros ISPs e os hosts aos quais eles estão conectados. Todos esses enlaces parecem iguais, não apenas 
porque não somos bons artistas, mas porque parte do papel de uma arquitetura de rede (conforme 
discutimos na Seção 1.3) é fornecer uma abstração comum de algo tão complexo e diversificado como 
um enlace. A ideia é que o seu laptop ou smartphone não tenha que se importar com o tipo de enlace 
ao qual está conectado — a única coisa que importa é que ele tem um enlace que o conecta à Internet. 
De modo semelhante, um roteador não precisa se importar com o tipo de enlace que o conecta a outros 
roteadores — ele pode enviar um pacote no enlace com uma expectativa muito boa de que o pacote 
alcançará a outra extremidade do enlace. 

Como fazemos todos esses diferentes tipos de enlace ficarem suficientemente parecidos para os 
usuários finais e roteadores? Basicamente, temos que lidar com todas as limitações físicas e deficiências 
dos enlaces que existem no mundo real. Esboçamos alguns desses problemas quando declaramos de 
problema, na abertura deste capítulo. O primeiro problema é que os enlaces são feitos de algum material 
físico capaz de propagar sinais (como ondas de rádio ou outros tipos de radiação eletromagnética), mas 
o que realmente queremos fazer é enviar bits. Em outras seções mais adiante neste capítulo, veremos 
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como codificar bits para transmissão em um meio físico, seguido por outras questões já mencionadas. 
Ao final deste capítulo, vamos entender como enviar pacotes completos por qualquer tipo de enlace, 
não importando qual seja o meio físico envolvido. 


CAPACIDADE DO ENLACE E O TEOREMA DE SHANNON-HARTLEY 


Existe uma enorme quantidade de trabalhos nas áreas relacionadas a processamento de sinais e teoria 
da informação, estudando tudo desde como os sinais se degradam com a distância até quantos dados 
determinado sinal pode transportar de modo eficaz. O trabalho mais notável nessa área é uma fórmula 
conhecida como teorema de Shannon-Hartley.? Em termos simples, esse teorema fornece um limite 
superior para a capacidade de um enlace, em termos de bits por segundo (bps) como uma função da 
relação sinal-ruído do enlace, medida em decibéis (dB) e da largura de banda do canal, medida em Hertz 
(Hz). (Conforme já observamos, largura de banda é um termo bastante utilizado em comunicações para 
coisas distintas; aqui, usamos esse termo para nos referir ao intervalo de frequências disponíveis para a 
comunicação.) 

Como um exemplo, podemos aplicar o teorema de Shannon-Hartley para determinar a taxa em que se 
espera que um modem discado transmita dados binários por uma linha telefônica projetada para transportar 
sinais de voz quando ele não sofre com uma taxa de erros muito alta. Uma linha telefônica padrão projetada 
para sinais de voz normalmente admite uma faixa de frequências de 300 Hz a 3.300 Hz, uma largura de banda 
de 3kHz pelo canal. 

O teorema normalmente é dado pela seguinte fórmula: 


C-Blog, (1+S/N) 


onde C é a capacidade alcançável pelo canal, medida em bits por segundo, B é a largura de banda do canal 
em Hz (3.300 Hz - 300 Hz =3.000 Hz), S é a potência média do sinal e N é a potência média do ruído. A relação 
sinal-ruído (S/N ou SNR - Signal to Noise Ratio) normalmente é expressa em decibéis, sendo calculada da 
seguinte forma: 


SNR=10log, (S/N) 


Assim, uma relação sinal-ruído típica de 30 dB indicaria que S/N= 1.000. Assim, temos 
C=3.000 log, (1.001) 


que vale aproximadamente 30 kbps. 

Quando os modems discados eram o principal meio de conexão com a Internet na década de 1990, 
56 kbps era uma capacidade anunciada comum para um modem (e continua a ser o limite superior para a 
conexão discada). Porém, os modems normalmente alcançavam velocidades menores na prática, pois nem 
sempre encontravam uma relação sinal-ruído alta o suficiente para alcançar 56 kbps. 

O teorema de Shannon-Hartley é igualmente aplicável a diversos tipos de enlaces, desde redes sem 
fio até o cabo coaxial e a fibra óptica. Deve-se notar que na realidade existem apenas duas maneiras 
de criar um enlace de alta capacidade: começar com um canal com elevada largura de banda ou obter 
uma elevada relação sinal-ruído ou, de preferência, ambos. Além disso, até mesmo essas condições não 
garantirão um enlace de alta capacidade - normalmente, é preciso muita engenhosidade por parte das 
pessoas que projetam esquemas de codificação de canal para alcançar os limites teóricos de um canal. Essa 
engenhosidade é particularmente visível hoje em dia nos enlaces sem fios, onde existe um grande incentivo 
para se obter o máximo de bits por segundo de determinada fatia do espectro sem fio (a largura de banda do 
canal) e nível de potência do sinal (e, portanto, SNR). 





2As vezes chamado simplesmente de teorema de Shannon, mas Shannon na realidade teve muitos teoremas. 





2.1.1 Classes de enlaces 


Embora a maioria dos leitores deste livro provavelmente já tenha encontrado pelo menos alguns tipos 
diferentes de enlaces, é importante entender algumas das principais classes de enlaces que existem e 
suas propriedades gerais. Para começar, todos os enlaces práticos contam com algum tipo de radiação 
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eletromagnética propagando-se por um meio ou, em alguns casos, pelo espaço livre. Uma forma de 
caracterizar os enlaces, portanto, é pelo meio que eles utilizam — normalmente, fio de cobre em alguma 
forma, como em um enlace DSL (Digital Subscriber Line, ou Linha de Assinante Digital) e cabo coaxial; 
fibra óptica, como em serviços comerciais fiber-to-the-home (fibra até em casa) e muitos enlaces de longa 
distância na espinha dorsal (backbone) da Internet; ou ar/espaço livre no caso de enlaces sem fio. 

Outra característica importante do enlace é a frequência, medida em Hertz, em que as ondas ele- 
tromagnéticas oscilam. A distância entre um par de pontos máximos ou mínimos adjacentes de uma 
onda, normalmente medida em metros, é chamada de comprimento de onda dessa onda. Como todas as 
ondas eletromagnéticas viajam na velocidade da luz (que por sua vez depende do meio), essa velocidade 
dividida pela frequência da onda é igual ao seu comprimento de onda. Já vimos o exemplo de uma linha 
telefônica projetada para sinais de voz, que transporta sinais eletromagnéticos contínuos variando entre 
300 Hz e 3.300 Hz; uma onda de 300 Hz trafegando pelo cobre teria um comprimento de onda de 


Velocidade da luz no cobre Frequência 


=2/3x3x10º +300 
=667x10º metros 


Geralmente, as ondas eletromagnéticas se espalham por uma faixa de frequências muito maior, 
variando desde ondas de rádio, luz infravermelha, luz visível, raios X e raios gama. A Figura 2.2 re- 
presenta o espectro eletromagnético e mostra quais meios normalmente são usados para transportar 
quais faixas de frequência. 

Até aqui entendemos que um enlace seja um meio físico transportando sinais na forma de ondas 
eletromagnéticas. Esses enlaces fornecem a base para transmitir todos os tipos de informação, incluindo 
o tipo de dado que estamos interessados em transmitir — dados binários (1s e 0s). Dizemos que os dados 
binários são codificados no sinal. O problema de codificar dados binários em sinais eletromagnéticos 
é um assunto complexo. Para ajudar a tornar o tópico mais fácil de entender, podemos pensar nele 
como sendo dividido em duas camadas. A camada inferior trata da modulação — variar a frequência, 
a amplitude ou a fase do sinal para efetuar a transmissão de informações. Um exemplo simples de 
modulação é variar a potência (amplitude) de um único comprimento de onda. Intuitivamente, isso é 
equivalente a acender e apagar uma luz. Como a questão da modulação é secundária à nossa discussão 
de enlaces como um bloco construtivo para redes de computadores, simplesmente assumimos que é 
possível transmitir um par de sinais distintos — pense neles como um sinal “alto” e um sinal “baixo” — e 
consideramos apenas a camada mais alta, que trata do problema muito mais simples de codificar dados 
binários nesses dois sinais. A Seção 2.2 discute essas codificações. 

Outra forma de classificar os enlaces é em termos de como eles são usados. Diversas questões 
econômicas e de implantação costumam influenciar onde diferentes tipos de enlace são encontrados. 
A maioria dos consumidores interage com a Internet ou por redes sem fio (que eles encontram em 
hotéis, aeroportos, universidades, etc.) ou pelos chamados enlaces da “última milha” fornecidos pelos 
provedores da Internet, conforme ilustrado na Tabela 2.1. Eles normalmente são escolhidos porque 
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FIGURA 2.2 Espectro eletromagnético. 
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Tabela 2.1 Serviços comuns disponíveis para conectar sua casa 





Serviço Largura de banda (típica) 
Discado 28 — 56 kbps 

ISDN 64 — 128 kbps 

DSL 128 kbps — 100 Mbps 
CATV (TV a cabo) 1-40 Mbps 

FTTH (Fibre To The Home) 50 Mbps — 1 Gbps 


são formas econômicas de alcançar milhões de consumidores; o DSL, por exemplo, foi desenvolvido 
para funcionar sobre os fios de cobre de par trançado que já existiam para os serviços de telefonia mais 
antigos. A maior parte dessas tecnologias não é suficiente para construir uma rede completa do zero — 
por exemplo, você provavelmente precisará de alguns enlaces de longa distância e de velocidade muito 
alta para interconectar cidades em uma rede grande. 

Hoje, os modernos enlaces de longa distância são quase exclusivamente de fibra, com a maioria 
dos cabos coaxiais tendo sido substituída durante as últimas décadas. Esses enlaces normalmente 
usam uma tecnologia chamada SONET (Synchronous Optical Network ou Rede Óptica Síncrona), que 
foi desenvolvida para atender aos rigorosos requisitos de gerenciamento das operadoras de telefonia. 
Veremos o SONET mais de perto na Seção 2.3.3. 

Finalmente, além dos enlaces da última milha e de backbone, existem enlaces que você encontra 
dentro de um prédio ou de uma universidade - normalmente chamados de redes locais (LANs). O 
Ethernet, descrito na Seção 2.6, tem sido há algum tempo a tecnologia dominante nesse espaço, tendo 
substituído as tecnologias token ring após muitos anos. Embora o Ethernet continue a ser popular, 
ele agora é visto principalmente ao lado de tecnologias sem fio baseadas nos padrões 802.11, que 
discutiremos na Seção 2.7. 

Este estudo dos tipos de enlace de forma alguma é definitivo, mas deve ter oferecido a você uma ideia 
da diversidade de tipos de enlace que existem e alguns dos motivos para essa diversidade. Nas próximas 
seções, veremos como os protocolos de rede podem tirar proveito dessa diversidade e apresentar uma 
visão consistente da rede para camadas mais altas, apesar de toda a complexidade de baixo nível. 


2.2 Codificação (NRZ, NRZI, Manchester, 4B/5B) 


O primeiro passo para transformar nós e enlaces em blocos construtivos utilizáveis é entender como 
conectá-los de tal forma que os bits possam ser transmitidos de um nó para o outro. Conforme men- 
cionamos na seção anterior, os sinais se propagam por enlaces físicos. A tarefa, portanto, é codificar os 
dados binários que o nó de origem deseja enviar nos sinais que os enlaces são capazes de transportar e 
depois decodificar o sinal de volta para os dados binários correspondentes no nó receptor. Ignoramos 
os detalhes da modulação e assumimos que estamos trabalhando com dois sinais discretos: alto e baixo. 
Na prática, esses sinais poderiam correspondem a duas tensões diferentes em um enlace baseado em 
cobre ou dois níveis de potência diferentes em um enlace óptico. 

A maior parte das funções discutidas neste capítulo são realizadas por um adaptador de rede — um 
dispositivo de hardware que conecta um nó a um enlace. O adaptador de rede contém um componente 
de sinalização que de fato codifica bits em sinais no nó emissor e decodifica sinais em bits no nó receptor. 
Assim, conforme ilustramos na Figura 2.3, os sinais trafegam por um enlace entre dois componentes 
de sinalização, e os bits fluem entre os adaptadores de rede. 


Componente de sinalização 


~ 
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i me Sinal `s, A : 
Nó Adaptador Adaptador Nó 
Bits FIGURA 2.3 Os sinais trafegam entre os componentes de 


>>> + sinalização; os bits fluem entre os adaptadores. 
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Vamos retornar ao problema de codificação de bits em sinais. A coisa mais óbvia a fazer é mapear 
dados cujo valor é 1 para o sinal alto e dados cujo valor é O para o sinal baixo. Esse é exatamente o 
mapeamento usado por um esquema de codificação chamado, enigmaticamente, de não retorno ao zero 
(non-return to zero — NRZ). Por exemplo, a Figura 2.4 representa esquematicamente o sinal codificado 
via codificação NRZ (parte inferior da figura) que corresponde à transmissão de uma determinada 
sequência de bits (no alto da figura). 

O problema com a codificação NRZ é que uma sequência de vários 1s consecutivos faz com que o 
sinal permaneça em alto no enlace por um longo período de tempo; de modo semelhante, vários Os 
consecutivos fazem com que o sinal permaneça em baixo por um longo intervalo. Existem dois pro- 
blemas fundamentais causados por longas sequências de 1s ou Os. O primeiro é que isso leva a uma 
situação conhecida como desvio da linha de base. Especificamente, o receptor mantém uma média do 
sinal que viu até o momento e depois usa essa média para distinguir entre sinais baixos e altos. Sempre 
que o sinal é significativamente mais baixo do que essa média, o receptor conclui que viu um 0; de 
modo semelhante, um sinal que é significativamente mais alto do que a média é interpretado como 
1. O problema, naturalmente, é que muitos 1s ou Os consecutivos fazem com que essa média mude, 
tornando mais difícil detectar uma mudança significativa no sinal. 

O segundo problema é que transições frequentes de alto para baixo e vice-versa são necessárias 
para permitir a recuperação do relógio. Intuitivamente, o problema de recuperação do relógio é 
que os processos de codificação e decodificação são controlados por um relógio — a cada ciclo do 
relógio o emissor transmite um bit e o receptor recupera um bit. Os relógios do emissor e do receptor 
precisam estar precisamente sincronizados para que o receptor recupere os mesmos bits que o 
emissor transmite. Se o relógio do receptor for ligeiramente mais rápido ou mais lento do que o 
relógio do emissor, então ele não decodificará o sinal corretamente. Você poderia pensar em enviar 
o relógio ao receptor por um fio separado, mas isso normalmente é evitado, pois dobra o custo do 
cabeamento. Assim, em vez disso, o receptor deriva o relógio a partir do sinal recebido — o processo 
de recuperação de relógio. Sempre que o sinal muda, como em uma transição de 1 para 0, ou de O 
para 1, o receptor sabe que está em um limite de ciclo de relógio, e pode se ressincronizar. Porém, 
um longo período de tempo sem essa transição leva a um desvio do relógio. Assim, a recuperação 
do relógio depende da existência de diversas transições no sinal, não importando quais dados estão 
sendo enviados. 

Uma técnica que resolve esse problema, chamada não retorno ao zero invertido (NRZI— non-return 
to zero inverted ), faz com que o emissor faça uma transição do valor atual do sinal para codificar um 1 
e permaneça no valor atual do sinal para codificar um 0. Isso resolve o problema de haver 1s consecu- 
tivos, mas obviamente não tem qualquer efeito sobre Os consecutivos. A codificação NRZI é ilustrada 
na Figura 2.5. Uma alternativa, chamada codificação Manchester, realiza uma tarefa mais explícita de 
combinar o relógio com o sinal, transmitindo o OU-exclusivo do valor do relógio com o valor dos dados 
codificados com o NRZ. (Pense no relógio local como um sinal interno que alterna entre baixo para alto; 
um par baixo/alto é considerado um ciclo de relógio.) A codificação Manchester também é ilustrada na 
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FIGURA 2.5 Diferentes estratégias de codificação. 
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Figura 2.5. Observe que a codificação Manchester faz com que um valor 0 seja codificado como uma 
transição de baixo para alto e com que um valor 1 seja codificado como uma transição de alto para 
baixo. Como 0s e 1s resultam ambos em transições do sinal, o relógio pode ser efetivamente recuperado 
no receptor. (Há também uma variante da codificação Manchester, chamada Manchester diferencial, 
em que um 1 é codificado fazendo com a primeira metade do sinal seja igual à última metade do sinal 
do bit anterior e um 0 é codificado fazendo com que a primeira metade do sinal seja o oposto da última 
metade do sinal do bit anterior.) 

O problema com o esquema de codificação Manchester é que ela dobra a taxa em que as tran- 
sições de sinal são feitas no enlace, o que significa que o receptor tem metade do tempo para 
detectar cada pulso do sinal. A taxa em que o sinal muda é chamada de taxa de bauds (baud rate) 
do enlace. No caso da codificação Manchester, a taxa de bits é metade da taxa de bauds, de modo 
que a codificação é considerada apenas 50% eficiente. Lembre-se de que, se o receptor fosse capaz 
de acompanhar a taxa de bauds mais rápida exigida pela codificação Manchester na Figura 2.5, 
então tanto NRZ como NRZI poderiam ter sido capazes de transmitir o dobro dos bits no mesmo 
período de tempo. 

Uma última codificação que consideramos, chamada 4B/5B, busca resolver a ineficácia da codificação 
Manchester sem sofrer com o problema de ter durações estendidas de sinais alto ou baixo. A ideia do 
4B/5B é inserir bits extras no fluxo de bits, de modo a quebrar longas sequências de Os ou 1s. Especi- 
ficamente, cada 4 bits de dados reais são codificados em um código de 5 bits que é então transmitido 
para o receptor; daí o nome 4B/5B. Os códigos de 5 bits são selecionados de modo que cada um deles 
não tenha mais do que um 0 inicial e não tenha mais do que dois Os finais. Assim, quando enviados 
um após o outro, nenhum par de códigos de 5 bits resulta em mais do que três Os consecutivos sendo 
transmitidos. Os códigos de 5 bits resultantes são então transmitidos usando a codificação NRZI, o que 
explica por que o código só trata de Os consecutivos — o NRZI já resolve o problema dos 1s consecutivos. 
Observe que a codificação 4B/5B resulta em 80% de eficiência. 

A Tabela 2.2 contém os códigos de 5 bits que correspondem a cada um dos 16 possíveis símbolos de 
dados de 4 bits. Observe que, como 5 bits são suficientes para codificar 32 códigos diferentes, e estamos 
usando apenas 16 deles para dados, existem 16 códigos restantes que podemos usar para outras finali- 
dades. Destes, o código 11111 é usado quando a linha está ociosa, o código 00000 corresponde a quando 
a linha está morta e 00100 é interpretado como significando interrupção. Dos 13 códigos restantes, sete 
deles não são válidos, pois violam a regra de “um 0 inicial, dois Os finais” e os outros seis representam 
diversos símbolos de controle. Conforme veremos mais adiante neste capítulo, alguns protocolos de 
enquadramento utilizam esses símbolos de controle. 


Tabela 2.2 Codificação 4B/5B 








Símbolo de dados de 4 bits Código de 5 bits 
0000 11110 
0001 01001 
0010 10100 
0011 10101 
0100 01010 
0101 01011 
0110 01110 
0111 01111 
000 10010 
001 10011 
010 10110 
01 10111 
100 11010 
101 11011 
110 11100 
111 11101 
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FIGURA 2.6 Bits fluem entre adaptadores, enquanto 
Bits quadros fluem entre hosts. 
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2.3 Enquadramento 


Agora que já vimos como transmitir uma sequência de bits por um enlace ponto a ponto — de adaptador 
a adaptador —, vamos considerar o cenário ilustrado na Figura 2.6. Lembre-se, do Capítulo 1, que temos 
como foco as redes de comutação de pacotes, o que significa que os blocos de dados (chamados quadros 
neste nível), e não os fluxos de bits, são trocados entre os nós. É o adaptador de rede que permite que 
os nós troquem quadros. Quando o nó A deseja transmitir um quadro ao nó B, ele diz ao seu adaptador 
para transmitir um quadro proveniente da memória do nó. Isso resulta em uma sequência de bits 
sendo enviada pelo enlace. O adaptador no nó B, então, coleta a sequência de bits que chega no enlace 
e deposita o quadro correspondente na memória de B. Reconhecer exatamente qual conjunto de bits 
constitui um quadro - ou seja, determinar onde o quadro começa e termina — é o desafio principal que 
o adaptador enfrenta. 

Existem diversas maneiras de resolver o problema de enquadramento. Esta seção usa vários protoco- 
los diferentes para ilustrar os diversos pontos no domínio do projeto. Observe que, apesar de discutirmos 
o enquadramento no contexto dos enlaces ponto a ponto, este é um problema fundamental que também 
precisa ser resolvido nas redes de acesso múltiplo como Ethernet e token rings. 


2.3.1 Protocolos orientados a byte (BISYNC, PPP DDCMP) 


Uma das técnicas mais antigas para o enquadramento — que tem suas raízes na conexão de terminais 
aos mainframes — é enxergar cada quadro como uma coleção de bytes (caracteres) em vez de uma 
coleção de bits. Essa técnica orientada a byte é exemplificada por protocolos mais antigos, como o 
protocolo Binary Synchronous Communication (BISYNC) desenvolvido pela IBM no final da década de 
1960, e o Digital Data Communication Message Protocol (DDCMP) usado na rede DECNET, da Digital 
Equipment Corporation. O mais recente e mais utilizado Point-to-Point Protocol (PPP) é outro exemplo 
dessa abordagem. 


Técnicas baseadas em sentinela 

A Figura 2.7 ilustra o formato de quadro do protocolo BISYNC. Essa figura é a primeira de muitas que 
você verá neste livro que usamos para ilustrar formatos de quadros ou pacotes, de modo que precisamos 
dar algumas explicações. Mostramos um pacote como uma sequência de campos rotulados. Acima de 
cada campo existe um número indicando o tamanho de cada campo em bits. Observe que os pacotes 
são transmitidos começando a partir do campo mais à esquerda. 

O BISYNC utiliza caracteres especiais, conhecidos como caracteres de sentinela, para indicar onde os 
quadros começam e terminam. O início de um quadro é indicado pelo envio de um caractere especial 
de SYN (Synchronization — Sincronização). A parte de dados do quadro está contida entre outros dois 
caracteres especiais: STX (Start of TeXt — Início do Texto) e ETX (End of TeXt — Fim do Texto). O campo 
SOH (Start Of Header — Início do Cabeçalho) tem a mesma finalidade do campo STX. O problema com a 
técnica de sentinela, logicamente, é que o caractere ETX pode aparecer na região de dados do quadro. O 
BISYNC contorna esse problema “deixando escapar” o caractere ETX, precedendo-o com um caractere 
DLE (Data-Link-Escape — Ponto de Escape de Dados) sempre que ele aparecer no corpo de um quadro; 
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8 8 8 16 16 8 FIGURA 2.8 Formato dos quadros PPP. 
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o caractere DLE também “é escapado” (precedendo-o com um DLE extra) no corpo do quadro. (Os 
programadores de C podem notar que isso é semelhante ao modo como as aspas são escapadas usando 
a barra invertida quando ela ocorre dentro de uma cadeia de caracteres.) Essa técnica normalmente 
é chamada de preenchimento de caracteres, pois caracteres extras são inseridos na região de dados do 
quadro. 

O formato do quadro também inclui um campo rotulado CRC (Cyclic Redundancy Check - verificação 
de redundância cíclica), que é usado para detectar erros de transmissão. Diversos algoritmos para 
detecção de erros são apresentados na Seção 2.4. Finalmente, o quadro contém outros campos de 
cabeçalho que são usados para, entre outras coisas, permitir entrega confiável do algoritmo da camada 
de enlace. Alguns exemplos desses algoritmos aparecem na Seção 2.5. 

O mais recente Point-to-Point Protocol (PPP), que normalmente é usado para transportar pacotes 
do IP (Internet Protocol) por diversos tipos de enlaces ponto a ponto, é semelhante ao BISYNC porque 
também usa sentinelas e preenchimento de caracteres. O formato para um quadro PPP pode ser visto na 
Figura 2.8. O caractere especial de início de texto, indicado como o campo Flag (marcador) na Figura 2.8, 
é 01111110. Os campos Endereço e Controle normalmente contêm valores padrão e, portanto, não são 
de interesse para nós. O campo Protocolo é usado para demultiplexação; ele identifica o protocolo de 
alto nível, como IP ou IPX (um protocolo semelhante ao IP desenvolvido pela Novell). O tamanho do 
payload (carga útil) do quadro pode ser negociado, mas é de 1.500 bytes por padrão. O campo Checksum 
(soma de verificação) pode ter 2 (o padrão) ou 4 bytes de comprimento. 

O formato dos quadros PPP é incomum porque vários dos tamanhos de campo são negociados, ao 
invés de fixos. Essa negociação é realizada por um protocolo chamado protocolo de controle de enlace 
(LCP — Link Control Protocol). O PPP e o LCP trabalham em conjunto: o LCP envia mensagens de controle 
encapsuladas em quadros PPP — essas mensagens são indicadas por um identificador LCP no campo 
Protocolo do PPP — e depois dá meia-volta e muda o formato de quadro do PPP com base na informação 
contida nessas mensagens de controle. O LCP também está envolvido no estabelecimento de uma ligação 
entre dois pares quando os dois lados detectam que a comunicação pelo enlace é possível (por exemplo, 
quando cada receptor óptico detecta a chegada de um sinal na fibra à qual está conectado). 


Técnica de contagem de bytes 

Como todo aluno iniciante em Ciência da Computação sabe, a alternativa ao uso de um valor de sen- 
tinela para detectar o final de um arquivo é incluir o número de itens presentes no arquivo no início 
deste arquivo. A mesma coisa acontece com o enquadramento — o número de bytes contidos em um 
quadro pode ser incluído como um campo no cabeçalho do quadro. O DDCMP da DECNET utiliza essa 
técnica, conforme ilustra a Figura 2.9. Nesse exemplo, o campo Contagem especifica quantos bytes estão 
contidos no corpo do quadro. 

Um risco com o uso dessa técnica é que um erro de transmissão poderia modificar o campo de 
contagem, e, assim, o final do quadro não seria detectado corretamente. (Um problema semelhante 
existe com a técnica baseada em sentinela se o campo ETX for modificado.) Se isso acontecer, o receptor 
acumulará tantos bytes quanto o campo Contagem indicar e depois usará o campo de detecção de 
erros para determinar se o quadro está errado. Isso, às vezes, é chamado de erro de enquadramento. 
O receptor então esperará até encontrar o próximo caractere SYN para começar a coletar os bytes que 
compõem o próximo quadro. Portanto, é possível que um erro de enquadramento faça com que os 
quadros sucessivos sejam recebidos incorretamente. 
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8 16 16 8 FIGURA 2.10 Formato dos quadros HDLC. 
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2.3.2 Protocolos orientados a bits (HDLC) 


Diferentemente desses protocolos orientados a bytes, um protocolo orientado a bits não se preocupa 
com fronteiras de bytes — ele simplesmente vê o quadro como uma coleção de bits. Esses bits poderiam 
vir de algum conjunto de caracteres, como o ASCII; eles poderiam ser valores de pixel em uma imagem; 
ou então poderiam ser instruções e operandos de um arquivo executável. O protocolo de controle de 
enlace de dados síncrono (SDLC — Synchronous Data Link Control), desenvolvido pela IBM, é um exem- 
plo de um protocolo orientado a bits; o SDLC foi mais tarde padronizado pela ISO como o protocolo 
High-Level Data Link Control (HDLC). Na discussão a seguir, usamos HDLC como um exemplo; seu 
formato de quadro é dado na Figura 2.10. 

O HDLC indica tanto o início como o final de um quadro com a sequência distintiva de bits 01111110. 
Essa sequência também é transmitida durante quaisquer momentos em que o enlace está ocioso, de 
modo que emissor e receptor podem manter seus relógios sincronizados. Desse modo, os dois protocolos 
basicamente utilizam a técnica de sentinela. Como essa sequência poderia aparecer em qualquer lugar 
no corpo do quadro — de fato, os bits 01111110 poderiam cruzar limites de byte —, os protocolos orienta- 
dos a bits utilizam a analogia do caractere DLE, uma técnica conhecida como preenchimento de bits. 

O preenchimento de bits no protocolo HDLC funciona da seguinte forma: no lado do emissor, toda 
vez que cinco 1s consecutivos forem transmitidos no corpo da mensagem (ou seja, exceto quando o 
emissor está tentando transmitir a sequência distintiva 01111110), o emissor insere um 0 antes de trans- 
mitir o próximo bit; no lado do receptor, se cinco 1s consecutivos chegarem, o receptor toma sua decisão 
com base no próximo bit que encontra (ou seja, o bit que vem após os cinco 1s). Se o próximo bit for 0, 
ele dever ser um bit de preenchimento, de modo que o receptor o remove. Se o próximo bit for 1, então 
pode-se ter uma de duas situações: ou esse é o marcador de fim de quadro ou um erro foi introduzido 
no conjunto de bits. Examinando o próximo bit, o receptor pode distinguir entre esses dois casos. Se ele 
for um 0 (ou seja, os 8 últimos bits que ele examinou foram 01111110), então esse é o marcador de fim 
de quadro; se ele for um 1 (ou seja, os 8 últimos bits que ele examinou foram 01111111), então deve ter 
havido um erro e o quadro inteiro é descartado. Nesse último caso, o receptor precisa esperar o próximo 
01111110 antes que possa começar a receber de novo e, como consequência, é possível que o receptor 
não consiga receber dois quadros consecutivos. Claro que ainda existem situações em que os erros de 
enquadramento não são detectados, como quando um falso padrão de fim de quadro inteiro é gerado 
por erros, mas essas falhas são relativamente improváveis. Outras formas mais rigorosas para detectar 
erros são discutidas na Seção 2.4. 

Uma característica interessante do preenchimento de bits, bem como do preenchimento de caracte- 
res, é que o tamanho de um quadro depende dos dados que estão sendo enviados no payload do quadro. 
De fato, não é possível fazer com que todos os quadros tenham exatamente o mesmo tamanho, visto 
que os dados que poderiam ser transportados em qualquer quadro são arbitrários. (Para se convencer 
disso, considere o que acontece se o último byte do corpo de um quadro for o caractere ETX.) Uma 
forma de enquadramento que garante que todos os quadros tenham o mesmo tamanho é descrita na 
próxima subseção. 


O QUE HÁ EM UMA CAMADA? 





Uma das contribuições importantes do modelo de referência OSI apresentado no Capítulo 1 é fornecer 
algum vocabulário para discutir sobre protocolos e, particularmente, camadas de protocolos. Esse 
vocabulário foi fonte de combustível para muitas discussões do tipo “Seu protocolo faz a função X na camada 
Y, e o modelo de referência OSI diz que isso deveria ser feito na camada Z — isso é uma violação de camadas”. 
De fato, descobrir a camada certa para realizar determinada função pode ser algo muito difícil, e o raciocínio 
normalmente é muito mais sutil do que “O que o modelo OSI diz?”. Em parte, é por esse motivo que este livro 


Capítulo 2 ° Conectando-se 55 





IER 





evita uma abordagem rigidamente em camadas. Em vez disso, ele lhe mostra muitas funções que precisam 
ser realizadas pelos protocolos e examina algumas maneiras como elas foram implementadas com sucesso. 

Apesar da nossa abordagem não voltada a camadas, às vezes precisamos de meios convenientes de falar 
sobre classes de protocolos, e o nome da camada em que esses protocolos operam normalmente é a melhor 
escolha. Assim, por exemplo, este capítulo se concentra principalmente nos protocolos da camada de enlace. 
(A codificação de bits, descrita na Seção 2.2, é a exceção, sendo considerada uma função da camada física.) 
Os protocolos da camada de enlace podem ser identificados pelo fato de serem executados sobre enlaces 
isolados — o tipo de rede discutido neste capítulo. Protocolos da camada de rede, ao contrário, trabalham 
em cima de redes comutadas, que contêm muitos enlaces interconectados por switches ou roteadores. Os 
tópicos relacionados aos protocolos da camada de rede são discutidos nos Capítulos 3 e 4. 

Observe que as camadas de protocolos deveriam ser úteis — elas fornecem meios úteis para falarmos 
sobre classes de protocolos e nos ajudam a dividir o problema da construir redes em subcamadas mais fáceis 
de administrar. Porém, elas não têm por finalidade ser extremamente restritivas — o simples fato de que algo 
é uma violação de camada não encerra a discussão sobre valer ou não a pena fazer isso. Em outras palavras, 
a disposição em camadas é boa para ser utilizada como linha geral, mas não precisa ser seguida cegamente. 
Um argumento particularmente interessante sobre a melhor camada para colocar uma certa função 
aparecerá quando examinarmos o controle de congestionamento, no Capítulo 6. 





2.3.3 Enquadramento baseado em relógio (SONET) 


Uma terceira técnica de enquadramento é exemplificada pelo padrão de rede óptica síncrona (SONET — 
Synchronous Optical Network). Por falta de um termo genérico amplamente aceito, vamos chamar essa 
técnica simplesmente de enquadramento baseado em relógio. A SONET foi proposta inicialmente pela 
Bell Communications Research (Bellcore) e desenvolvida em seguida pelo American National Standards 
Institute (ANSI) para transmissão digital por fibra óptica; desde então, foi adotada pela ITU-T. Há muitos 
anos o SONET tem sido o padrão mais utilizado para a transmissão de dados em longa distância por 
meio de redes ópticas. 

Um ponto importante sobre a SONET, antes de entrarmos em mais detalhes, é que a sua especificação 
completa é substancialmente maior do que este livro. Assim, a discussão a seguir necessariamente 
abordará apenas os pontos principais do padrão. Além disso, a SONET trata tanto do problema de 
enquadramento como do problema de codificação. Ela também trata de um problema que é muito 
importante para as companhias telefônicas —- a multiplexação de vários enlaces de baixa velocidade 
em um enlace de alta velocidade. (De fato, grande parte do projeto da SONET reflete o fato de que as 
companhias telefônicas precisam se preocupar com a multiplexação de grandes quantidades de canais 
de 64 kbps que tradicionalmente são usados para ligações telefônicas.) Começamos com a técnica de 
enquadramento do SONET e em seguida discutimos as outras questões. 

Assim como nos esquemas de enquadramento discutidos anteriormente, um quadro SONET possui 
algumas informações especiais que dizem ao receptor onde o quadro começa e termina; porém, as 
semelhanças terminam aí. Particularmente, nenhum preenchimento de bits é usado, de modo que o 
tamanho do quadro não depende dos dados sendo enviados. Logo, a pergunta é: “Como o receptor sabe 
onde cada quadro começa e termina?”. Consideremos essa pergunta para o enlace SONET de menor 
velocidade, que é conhecido como STS-1 e opera a 51,84 Mbps. Uma representação do quadro STS-1 
pode ser vista na Figura 2.11. Ele é estruturado como 9 linhas de 90 bytes cada, e os três primeiros bytes 
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- 90 colunas » FIGURA 2.11 Um quadro STS-1 do SONET. 
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de cada linha são overhead, com o restante ficando disponível para os dados que estão sendo trans- 
mitidos pelo enlace. Os dois primeiros bytes do quadro contêm uma sequência de bits especial, e são 
esses bytes que permitem que o receptor determine onde o quadro começa. Porém, como o preen- 
chimento de bit não é usado, não há motivo para que essa sequência ocasionalmente não apareça na 
porção de payload do quadro. Para evitar isso, o receptor procura consistentemente pela sequência de 
bits especial, esperando vê-lo aparecer uma vez a cada 810 bytes, pois cada quadro tem 9x 90=810 bytes 
de extensão. Quando a sequência especial aparece no local correto por um número suficiente de vezes, 
o receptor conclui que ele está sincronizado e pode então interpretar o quadro corretamente. 

Uma das coisas que não estamos descrevendo devido à complexidade do SONET é o uso detalhado 
de todos os outros bytes de overhead. Parte dessa complexidade pode ser atribuída ao fato de que o 
SONET atua sobre a rede óptica da operadora, e não apenas sobre um único enlace. (Lembre-se de que 
estamos apenas pincelando o fato de que as operadoras implementam uma rede, e nos concentrando 
no fato de que podemos alugar um enlace SONET controlado por elas e depois usamos esse enlace para 
montar nossa própria rede de comutação de pacotes.) A complexidade adicional vem do fato de que o 
SONET oferece um conjunto consideravelmente mais rico de serviços do que apenas transferência de 
dados. Por exemplo, 64 kbps da capacidade de um enlace SONET são separados para um canal de voz 
que é usado para tarefas de manutenção. 

Os bytes de overhead de um quadro SONET são codificados usando NRZ, a codificação simples 
descrita na seção anterior, onde 1s são alto e Os são baixo. Porém, para garantir que exista um número 
suficiente de transições para permitir que o receptor recupere o sinal de relógio do emissor, os bytes 
do payload são embaralhados. Isso é feito calculando o OU-exclusivo (XOR) dos dados a serem trans- 
mitidos e pelo uso de uma sequência de bits bem conhecida. A sequência de bits, que tem 127 bits de 
comprimento, possui muitas transições de 1 para 0, de modo que o XOR dele com os dados transmitidos 
provavelmente gerará um sinal com transições suficientes para permitir a recuperação do relógio. 

O SONET admite a multiplexação de vários enlaces de baixa velocidade da seguinte maneira: deter- 
minado enlace SONET trabalha com um dentre um conjunto finito de velocidades possíveis, variando 
de 51,84 Mbps (STS-1) a 2488,32 Mbps (STS-48) e superiores. Observe que todas essas velocidades 
são múltiplos inteiros da STS-1. A consequência para o processo de enquadramento é que um único 
quadro SONET pode conter subquadros para vários canais de velocidade inferior. Um segundo recurso 
relacionado é que cada quadro possui 125 us de comprimento. Isso significa que, em velocidades STS-1, 
um quadro SONET tem 810 bytes de extensão, enquanto em velocidades STS-3, cada quadro SONET 
tem 2.430 bytes de extensão. Observe a sinergia entre esses dois recursos: 3 x 810=2.430, o que significa 
que três quadros STS-1 cabem perfeitamente em um único quadro STS-3. 

Intuitivamente, podemos pensar no quadro STS-N como consistindo em N quadros STS-1, no qual 
os bytes desses quadros são intercalados; ou seja, um byte do primeiro quadro é transmitido, depois 
um byte do segundo quadro é transmitido, e assim por diante. O motivo para intercalar os bytes de cada 
quadro STS-N é para garantir que os bytes em cada quadro STS-1 sejam igualmente espaçados; ou seja, 
os bytes aparecem no receptor distribuídos pelos 51 Mbps, em vez de todos eles entulhados durante 
um período particular de 1/N dentro do intervalo de 125 ps. 

Embora seja mais correto enxergar um sinal STS-N como sendo usado para multiplexar N quadros 
STS-1, os payloads desses quadros STS-1 podem ser interligados para formar um payload STS-N maior; 
esse enlace é denotado como STS-Nc (de concatenado). Um dos campos no overhead de controle é usado 
para essa finalidade. A Figura 2.12 representa esquematicamente essa concatenação no caso de três 
quadros STS-1 sendo concatenados em um único quadro STS-3c. A importância de designar um enlace 
SONET como STS-3c em vez de STS-3 é que, no primeiro caso, o usuário do enlace pode vê-lo como 
um único canal de 155,25 Mbps, enquanto um STS-3 na realidade deveria ser visto como três enlaces 
de 51,84 Mbps que compartilham uma fibra. 

Finalmente, a descrição anterior do SONET é extremamente simplificada porque considera que o 
payload para cada quadro está completamente contido dentro do quadro. (Por que não estaria?) Na 
verdade, devemos enxergar o quadro STS-1 recém-descrito como simplesmente um espaço virtual 
ocupado pelo quadro, já que o payload real pode flutuar através dos limites de quadro. Essa situação é 
ilustrada na Figura 2.13. Aqui, vemos o payload STS-1 flutuando por dois quadros STS-1, com o payload 
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deslocado de um certo número de bytes para direita e, portanto, retorcido ciclicamente Um dos campos 
do overhead do quadro aponta para o início do payload. A importância desta funcionalidade é que 
ela simplifica a tarefa de sincronizar os relógios usados pelas redes das operadoras, que é algo que as 
operadoras gastam muito tempo se preocupando em fazer. 


2.4 Detecção de erros 


Conforme discutimos no Capítulo 1, erros de bits às vezes são introduzidos nos quadros. Isso acontece, 
por exemplo, devido à interferência elétrica ou ruído térmico. Embora os erros sejam raros, especial- 
mente em enlaces ópticos, é necessário que haja algum mecanismo para detectar esses erros, de modo 
que uma ação corretiva possa ser tomada. Caso contrário, o usuário final pode ficar se perguntando 
por que o programa em C que compilou corretamente há um momento atrás de repente apresenta 
um erro de sintaxe; tudo o que aconteceu durante esse tempo foi ele ser copiado por meio de um sistema 
de arquivos de rede. 

Há uma longa história de técnicas para lidar com os erros de bit nos sistemas computacionais, que 
datam pelo menos da década de 1940. Os códigos de Hamming e Reed-Solomon são dois exemplos em 
particular que foram desenvolvidos para uso em leitoras de cartão perfurado, para armazenar dados 
em discos magnéticos e nas primeiras memórias em núcleos de processamento. Esta seção descreve 
algumas das técnicas de correção de erro mais utilizadas nas redes. 

A detecção de erros é apenas uma parte do problema. A outra parte é a correção dos erros, uma vez 
detectados. Duas técnicas básicas podem ser usadas quando o destinatário de uma mensagem detecta 
um erro. Uma é notificar o emissor de que a mensagem foi modificada, para que ele possa retrans- 
mitir uma cópia da mensagem. Se os erros de bit são raros, então com toda a probabilidade a cópia 
retransmitida estará livre de erros. Como alternativa, alguns tipos de algoritmos de detecção de erros 
permitem que o destinatário reconstrua a mensagem correta mesmo depois de ela ter sido alterada; 
esses algoritmos se baseiam em códigos corretores de erros, discutidos mais adiante. 

Uma das técnicas mais comuns para detectar erros de transmissão é uma técnica conhecida como 
verificação de redundância cíclica (CRC — Cyclic Redundancy Check). Ela é usada em quase todos os 
protocolos da camada de enlace discutidos na seção anterior (por exemplo, HDLC, DDCMP), além do 
CSMA e protocolos sem fios descritos mais adiante neste capítulo. A Seção 2.4.3 esboça o algoritmo 
CRC básico. Antes de discutirmos essa técnica, consideremos dois esquemas mais simples: paridade 
bidimensional e somas de verificação. A primeira é usada pelo protocolo BISYNC quando está trans- 
mitindo caracteres ASCII (usa-se CRC como código de detecção de erros quando o BISYNC é usado para 
transmitir EBCDIC),º e a segunda é usada por diversos protocolos da Internet. 

Aideia básica por trás de qualquer esquema de detecção de erros é acrescentar informações redun- 
dantes em um quadro, que possam ser usadas para determinar se foram introduzidos erros. No caso 
extremo, poderíamos imaginar a transmissão de duas cópias completas dos dados. Se as duas cópias 
forem idênticas no receptor, então provavelmente ambas estão corretas. Se forem diferentes, então foi 
introduzido um erro em uma delas (ou ambas), e elas precisam ser descartadas. Esse é um esquema 


“Um esquema de codificação de caracteres alternativo, usado na década de 1960. 
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de detecção de erros muito fraco por dois motivos. Primeiro, ele envia n bits redundantes para uma 
mensagem com n bits. Segundo, muitos erros não serão detectados — qualquer erro que modifique as 
mesmas posições de bit na primeira e segunda cópias da mensagem. Em geral, o objetivo dos códigos de 
detecção de erros é fornecer uma alta probabilidade de detectar erros em combinação com um número 
de bits redundantes relativamente baixo. 

Felizmente, podemos fazer muito melhor do que esse esquema simples. Em geral, podemos oferecer 
uma capacidade de detecção de erros bastante forte enquanto enviamos apenas k bits redundantes 
para uma mensagem com n bits, onde k << n. Em uma rede Ethernet, por exemplo, um quadro 
transportando até 12.000 bits (1.500 bytes) de dados exige apenas um código CRC de 32 bits ou, como 
normalmente é denotado, utiliza um CRC-32. Esse código detectará a maioria esmagadora dos erros, 
conforme veremos mais adiante. 

Dizemos que os bits extras que enviamos são redundantes porque não acrescentam informações 
novas à mensagem. Em vez disso, eles são derivados diretamente da mensagem original, usando algum 
algoritmo bem definido. Tanto o emissor como o receptor sabem exatamente qual é esse algoritmo. O 
emissor aplica o algoritmo à mensagem para gerar os bits redundantes. Depois, ele transmite a mensa- 
gem e esses poucos bits extras. Quando o receptor aplica o mesmo algoritmo à mensagem recebida, ele 
deve (na ausência de erros) chegar ao mesmo resultado do emissor. Ele compara o resultado com aquele 
que foi enviado pelo emissor. Se forem iguais, ele poderá concluir (com uma alta probabilidade) que 
nenhum erro foi introduzido na mensagem durante sua transmissão. Se não forem iguais, ele poderá 
estar certo de que ou a mensagem ou os bits redundantes foram modificados, devendo assim tomar 
uma ação apropriada - ou seja, descartar a mensagem ou corrigi-la, se isso for possível. 

Uma observação sobre a terminologia para esses bits extras: em geral, eles são chamados de códigos de 
detecção de erros. Em casos específicos, quando o algoritmo para criar o código é baseado na operação 
de adição, eles podem ser chamados de soma de verificação. Veremos que a soma de verificação na Internet 
é nomeada de forma apropriada: é uma verificação de erros que usa um algoritmo de somatória. Infeliz- 
mente, o termo soma de verificação frequentemente é usado de modo impreciso para indicar qualquer 
forma de código de detecção de erros, incluindo CRCSs. Isso pode ser confuso, de modo que recomendamos 
o uso de soma de verificação apenas quando se referir a códigos que realmente usam operações de adição 
e o uso de código de detecção de erros para se referir à classe geral de códigos descritos nesta seção. 


2.4.1 Paridade bidimensional 


A paridade bidimensional é exatamente o que o nome sugere. Ela é baseada na paridade “simples” (uni- 
dimensional), que normalmente envolve acrescentar um bit extra a um código de 7 bits para balancear o 
número de 1s no byte. Por exemplo, a paridade ímpar fixa o oitavo bit em 1 se isso for necessário para obter 
um número ímpar de Is no byte, e a paridade par fixa o oitavo bit em 1 se isso for necessário para gerar um 
número par de 1s no byte. A paridade bidimensional faz um cálculo semelhante para cada posição de bit 
considerando cada um dos bytes contidos no quadro. Isso resulta em um byte de paridade extra para o 
quadro inteiro, além do bit de paridade de cada byte. A Figura 2.14 ilustra como funciona a paridade par 
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FIGURA 2.14 Paridade bidimensional. 
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bidimensional para um quadro de exemplo contendo 6 bytes de dados. Observe que o terceiro bit do byte 
de paridade é 1, pois existe um número ímpar de Is quando se considera o terceiro bit dos 6 bytes do 
quadro. Pode-se mostrar que a paridade bidimensional detecta todos os erros de 1,2 e 3 bits, e a maioria 
dos erros de 4 bits. Nesse caso, adicionamos 14 bits de informação redundante a uma mensagem de 42 
bits, e ainda temos uma proteção mais forte contra erros comuns do que o “código de repetição” descrito 
anteriormente. 


2.4.2 Algoritmo de soma de verificação da Internet 


Uma outra técnica de detecção de erros é exemplificada pela soma de verificação da Internet. Embora não 
seja usada no nível de enlace, de qualquer forma ela oferece o mesmo tipo de funcionalidade dos CRCs 
e da paridade, e por isso a discutimos aqui. Veremos exemplos de seu uso nas Seções 3.2, 5.1 e 5.2. 

A ideia por trás da soma de verificação da Internet é muito simples — você soma todas as palavras 
que são transmitidas e depois transmite o resultado dessa soma. O resultado é a soma de verificação. 
O receptor realiza o mesmo cálculo sobre os dados recebidos e compara o resultado com a soma de 
verificação recebida. Se algum dado transmitido, incluindo a própria soma de verificação, for alterado, 
então os resultados não coincidirão, de modo que o receptor saberá que houve um erro. 

Você pode imaginar muitas variações diferentes a partir da ideia básica de uma soma de verificação. 
O esquema exato utilizado pelos protocolos da Internet funciona da seguinte maneira. Considere os 
dados sendo somados para verificação como uma sequência de inteiros de 16 bits. Some-os usando a 
aritmética de complemento de um para 16 bits (que explicamos em seguida) e depois calcule o com- 
plemento de um do resultado. Esse número de 16 bits é a soma de verificação. 

Na aritmética de complemento de um, um inteiro negativo (-x) é representado como o complemento 
de x; ou seja, cada bit de x é invertido. Ao somar números na aritmética de complemento de um, um 
“vai-um” no bit mais significativo precisa ser somado ao resultado. Considere, por exemplo, a soma de 
-5 e -3 na aritmética de complemento de um sobre inteiros de 4 bits: +5 é 0101, de modo que -5 é 1010; 
+3 é 0011, de modo que -3 é 1100. Se somarmos 1010 e 1100, ignorando o vai-um, obtemos 0110. Na 
aritmética de complemento de um, o fato de que essa operação causou um vai-um no bit mais signifi- 
cativo nos faz incrementar o resultado, gerando 0111, que é -8 na representação em complemento de 
um (valor obtido invertendo-se os bits de 1000), como é de se esperar. 

A rotina a seguir é uma implementação simples do algoritmo de soma de verificação da Internet. O 
argumento count corresponde ao tamanho de buf medido em unidades de 16 bits. A rotina considera 
que buf já foi preenchido com Os até a fronteira dos 16 bits. 





ei 
cksum(u short *buf, int count) 
{ 


reg 


u s 


ister u_long sum = O; 








while (count--) 

{ 

sum += *buf++; 

if (sum & OxFFFFOOO0) 

/* houve vai-um, portanto some-o no início */ 
sum &= OxFFFF; 

sum++ ; 

return - (sum & OxFFFF); 


Este código garante que o cálculo usa a aritmética de complemento de um ao invés do complemento 
de dois que é usado na maioria das máquinas. Observe a instrução if dentro do laço de while. Se houver 
um vai-um nos 16 bits mais significativos de sum, então incrementamos sum assim como no exemplo 
anterior. 

Comparado com nosso código de repetição, este algoritmo é muito bom no que se refere ao uso de 
um pequeno número de bits redundantes — apenas 16 para uma mensagem de qualquer tamanho -, 
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mas não é tão bom com relação à sua capacidade de detectar erros. Por exemplo, um par de erros que 
alterem apenas dois bits, um deles incrementando uma palavra e outro decrementando outra palavra 
pelo mesmo valor, não será detectado. O motivo para usar um algoritmo como esse, apesar de sua 
proteção relativamente fraca contra erros (em comparação com um CRC, por exemplo) é simples: o 
algoritmo é muito mais fácil de implementar em software. A experiência na ARPANET sugeriu que uma 
soma de verificação dessa forma era adequada. Um motivo para isso é que essa soma de verificação é 
a última linha de defesa em um protocolo fim a fim; a maioria dos erros é detectada por algoritmos de 
detecção de erros mais fortes, como CRCs, no nível de enlace. 


CÁLCULOS PROBABILÍSTICOS SIMPLES 


Ao lidar com erros de rede e outros eventos pouco prováveis (assim esperamos), frequentemente utilizamos 
estimativas probabilísticas simples, aproximadas. Uma aproximação útil aqui é que, se dois eventos 
independentes possuem baixas probabilidades p e q, então a probabilidade de qualquer evento é p+q; a resposta 
exataé1-(1-p)(1-q)=p+q-pg.Para p=9=0,01, essa estimativa é 0,02, quando o valor exato é 0,0199. 

Para mostrar uma aplicação simples disso, suponha que a taxa de erros por bit em um enlace seja 1 
em 10. Agora, suponha que estejamos interessados em estimar a probabilidade de pelo menos um bit em 
um pacote de 10.000 bits estar com erro. Usando a aproximação anterior repetidamente por todos os bits, 
podemos dizer que estamos interessados na probabilidade de o primeiro bit estar errado, ou o segundo bit, 
ou o terceiro etc. Considerando que os erros de bit são todos independentes (o que não é o caso), podemos 
portanto estimar que a probabilidade de pelo menos um erro em um pacote de 10.000 bits (10º bits) é de 
10!x 107=103. A resposta exata, calculada como 1 — P(não haver erros), seria 1 — (1 — 1019-990 =0,00099950. 

Para mostrar uma aplicação ligeiramente mais complexa, calculamos a probabilidade de exatamente 
dois erros em um pacote desse tipo; essa é a probabilidade de um erro que passaria desapercebido por uma 
soma de verificação correspondente a 1 bit de paridade. Se considerarmos dois bits em particular no pacote, 


digamos, o bit i e o bit j, a probabilidade desses bits exatos estarem errados é 107 x 107. Agora, o número 
4 


total de pares de bits possíveis no pacote é [o x(10º -1) /2=5x10”. Portanto, novamente usando 


a aproximação de somar as probabilidades de muitos eventos raros (neste caso, de qualquer par de bits 
possível estar errado), nossa probabilidade de pelo menos dois bits errados é 5 x 10” x 10-!!=5 x 107. 





2.4.3 Verificação de redundância cíclica (CRC) 


Neste ponto, deve estar claro que um objetivo importante no projeto de algoritmos de detecção de erros 
é maximizar a probabilidade de detectar erros usando apenas um pequeno número de bits redundantes. 
As verificações de redundância cíclica utilizam algumas ferramentas matemáticas razoavelmente pode- 
rosas para atingir esse objetivo. Por exemplo, um CRC de 32 bits oferece proteção forte contra erros de 
bit comuns em mensagens que contêm milhares de bytes. A fundamentação teórica da verificação 
de redundância cíclica etm suas bases em um ramo da matemática chamado corpos finitos. Embora 
isso possa soar assustador, as ideias básicas podem ser facilmente compreendidas. 

Para começar, pense em uma mensagem de (n+ 1) bits como sendo representada por um polinômio 
de grau n, ou seja, um polinômio cujo termo de mais alta ordem é x”. A mensagem é representada por um 
polinômio, usando o valor de cada bit da mensagem como coeficiente para cada termo do polinômio, 
começando com o bit mais significativo para representar o termo de mais alta ordem. Por exemplo, uma 
mensagem de 8 bits consistindo nos bits 10011010 corresponde ao polinômio 


M(x)=1xx" +0xxº +0xxº +1xxº 


+1xxº +0xx2 +1xx! 





+0xxº 
=x"+xº 4x) +x" 


Assim, podemos pensar em um emissor e um receptor como entidades que trocam polinômios entre elas. 
Para fins de cálculo de um CRC, um emissor e um receptor precisam entrar em acordo com relação a 
um polinômio divisor, C(x). C(x) é um polinômio de grau k. Por exemplo, suponha que C(x) =x +x?+1. 
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Nesse caso, k=3. A resposta à pergunta “De onde veio C(x)?” é, na maior parte dos casos práticos, “Você 
pesquisa isso em um livro”. Na realidade, a escolha de C(x) tem um impacto significativo sobre os tipos 
de erros que podem ser detectados de modo confiável, conforme discutiremos em seguida. Existem 
alguns polinômios divisores que são muito boas escolhas para diversos ambientes, e a escolha exata 
normalmente é feita como parte do projeto do protocolo. Por exemplo, o padrão Ethernet usa um 
polinômio de grau 32 bem conhecido. 

Quando um emissor deseja transmitir uma mensagem M(x) que possui n+ 1 bits de comprimento, o que 
realmente é enviado é a mensagem de (n+ 1) bits mais k bits. Chamamos a mensagem transmitida com- 
pleta, incluindo os bits redundantes, de P(x). O que iremos fazer é garantir que o polinômio representando 
P(x) seja divisível exatamente por C(x); explicaremos como isso é feito mais adiante. Se P(x) é transmitido 
por um enlace e não existem erros introduzidos durante a transmissão, então o receptor deverá ser capaz 
de dividir P(x) por C(x) exatamente, deixando um resto zero. Entretanto, se algum erro for introduzido em 
P(x) durante a transmissão, então com certeza o polinômio recebido não será mais divisível exatamente 
por C(x) e o receptor obterá um resto diferente de zero, significando que houve um erro. 

É importante entender o seguinte caso você não seja um grande conhecedor de aritmética polinomial: 
ela é um pouco diferente da aritmética normal com inteiros. Estamos lidando com uma classe especial de 
aritmética polinomial aqui, em que os coeficientes podem ser apenas 1 ou 0, e as operações sobre os coefi- 
cientes são realizadas usando aritmética módulo 2. Isso é conhecido como “aritmética polinomial módulo 
2”. Como este é um livro sobre redes, e não um texto sobre matemática, vamos focalizar as propriedades 
principais desse tipo de aritmética útil para nossos propósitos (que pedimos que você aceite pela fé): 


e Qualquer polinômio B(x) pode ser dividido por um polinômio divisor C(x) se B(x) tiver um grau 
maior do que C(x). 

e Qualquer polinômio B(x) pode ser dividido uma vez por um polinômio divisor C(x) se B(x) tiver o 
mesmo grau que C(x). 

e Oresto obtido quando B(x) é dividido por B(x) é obtido realizando-se a operação de OU exclusivo 
(XOR) sobre cada par de coeficientes correspondentes. 


Por exemplo, o polinômio x? + 1 pode ser dividido por xº+x2+1 (pois ambos têm grau 3) e o resto 
seria 0 xxº+1xxº+0xx!+0xxº=x2 (obtido calculando-se o XOR dos coeficientes de cada termo). Em 
termos de mensagens, poderíamos dizer que 1001 pode ser dividido por 1101 e deixar um resto de 0100. 
Você pode perceber que o resto é simplesmente o OU exclusivo bit a bit das duas mensagens. 

Agora que conhecemos as regras básicas para dividir polinômios, podemos calcular uma divisão 
longa, que é necessária para lidar com mensagens maiores. Um exemplo aparece a seguir. 

Lembre-se de que queríamos criar um polinômio para a transmissão que seja derivado da mensagem 
original M(x), seja k bits maior do que M(x) e seja divisível exatamente por C(x). Podemos fazer isso da 
seguinte maneira: 


1. Multiplique M(x) por x*; ou seja, acrescente k zeros ao final da mensagem. Chame essa mensagem 
estendida com zeros de T(x). 

2. Divida T(x) por C(x) e determine o resto. 

3. Subtraia o resto de T(x). 


Deve estar claro que o que restou agora é uma mensagem que é divisível exatamente por C(x). 
Também podemos observar que a mensagem resultante corresponde a M(x) seguido pelo resto obtido 
no item 2, pois quando subtraímos o resto (que não pode ter mais de k bits de extensão), realizamos o 
XOR dele com os k zeros acrescentados no item 1. Essa parte ficará mais clara com um exemplo. 

Considere a mensagem x'+x*+xº+x!, ou 10011010. Começamos multiplicando-a por xº, pois nosso 
polinômio divisor tem grau 3. Isso resulta em 10011010000. Dividimos este resultado por C(x), que 
corresponde a 1101 neste caso. A Figura 2.15 mostra a operação polinomial da divisão longa. Com as 
regras da aritmética polinomial descritas acima, a operação de divisão longa é feita como se estivéssemos 
dividindo inteiros. Assim, na primeira etapa do nosso exemplo, vemos que o divisor 1101 divide uma 
vez os primeiros quatro bits da mensagem (1001), pois eles têm o mesmo grau, e deixa um resto de 100 
(1101 XOR 1001). O próximo passo é “baixar” um dígito do polinômio da mensagem, até que obtenhamos 
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11111001 FIGURA 2.15 Cálculo do CRC usando a divisão polinomial longa. 
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outro polinômio com o mesmo grau de C(x), neste caso, 1001. Calculamos o resto novamente (100) e 
continuamos até que o cálculo esteja completo. Observe que o “resultado” da divisão longa, que aparece 
no alto do cálculo, na realidade não é tão interessante — o que importa é o resto no final. 

Você pode ver na parte inferior da Figura 2.15 que o resto do cálculo em nosso exemplo é 101. Assim, 
sabemos que 10011010000 menos 101 seria exatamente divisível por C(x), e é isso que enviamos. A 
operação de subtração na aritmética polinomial é a operação lógica XOR, de modo que na realidade 
enviamos 10011010101. Conforme observamos, essa é exatamente a mensagem original com o resto do 
cálculo da divisão longa acrescentado a ela. O destinatário divide o polinômio recebido por C(x) e, se o 
resultado for 0, conclui que não houveram erros. Se o resultado for diferente de zero, pode ser preciso 
descartar a mensagem modificada; com alguns códigos, pode ser possível corrigir um erro pequeno 
(por exemplo, se o erro afetou apenas um bit). Um código que permite a correção de erros é chamado 
de código corretor de erros (ECC — Error-Correcting Code). 

Agora, vamos considerar a questão sobre de onde vem o polinômio C(x). Intuitivamente, a ideia 
é selecionar esse polinômio de modo que seja muito improvável que a divisão seja exata para uma 
mensagem que possui erros. Se a mensagem transmitida for P(x), podemos pensar na introdução de 
erros como o acréscimo de outro polinômio E(x), de modo que o destinatário vê P(x) + E(x). A única 
maneira em que um erro poderia passar sem ser notado seria se a mensagem recebida pudesse ser 
dividia exatamente por C(x), e como sabemos que P(x) pode ser dividido exatamente por C(x), isso 
poderia acontecer se E(x) puder ser dividido exatamente por C(x). O truque é escolher C(x) de modo 
que isso seja muito pouco provável para os tipos de erros mais comuns. 

Um tipo de erro comum é um erro de único bit, que pode ser expresso como E(x) =x' quando ele 
afeta a posição de bit i. Se selecionarmos C(x) de modo que o primeiro e o último termo (ou seja, os 
termos x* e x?) sejam diferentes de zero, então já temos um polinômio de dois termos que não pode ser 
dividido exatamente pelo polinônimo de um único termo E(x). Tal C(x) pode, portanto, detectar todos 
os erros de único bit. Em geral, é possível provar que os seguintes tipos de erros podem ser detectados 
por um C(x) com as propriedades indicadas: 


e Todos os erros de único bit, desde que os termos x* e x? tenham coeficientes diferentes de zero 
e Todos os erros de dois bits, desde que C(x) tenha um fator com pelo menos três termos 
e Qualquer número ímpar de erros, desde que C(x) contenha o fator (x+1) 
e Qualquer erro em “rajada” (ou seja, sequência de bits consecutivos com erro) para o qual 
o tamanho da rajada seja menor que k bits (a maioria dos erros de rajada com tamanho maior 
que k bits também pode ser detectada). 





DETECÇÃO DE ERRO OU CORREÇÃO DE ERRO? 


Já dissemos que é possível usar códigos que não apenas detectam a presença de erros, mas que também 
permitem que os erros sejam corrigidos. Como os detalhes desses códigos exigem uma matemática ainda 
mais complexa do que aquela necessária para entender CRCs, não vamos mergulhar nisso aqui. Porém, vale 
a pena considerarmos os méritos da correção versus a detecção. 
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À primeira vista, pode parecer que a correção sempre é a melhor alternativa, pois com a detecção somos 
forçados a descartar a mensagem e, em geral, pedir que outra cópia seja transmitida. Isso ocupa largura de 
banda e pode aumentar a latência enquanto se espera a retransmissão. Porém, existe um lado negativo na 
correção, pois geralmente ela exige um maior número de bits redundantes para enviar um código corretor de 
erros que seja tão forte (ou seja, capaz de tratar a mesma quantidade de erros) quanto um código que apenas 
detecta erros. Assim, embora a detecção de erros exija que mais bits sejam enviados quando ocorrerem erros, 
a correção de erros exige o envio de mais bits o tempo todo. Como resultado, a correção de erros costuma ser 
mais útil quando (1) os erros são bastante prováveis, como poderia acontecer, por exemplo, em um ambiente 
sem fios, ou (2) o custo da retransmissão é muito alto, por exemplo, devido à latência envolvida 
na retransmissão de um pacote por um enlace de satélite. 

O uso dos códigos corretores de erros em redes às vezes é chamado de correção antecipada de erros 
(FEC — Forward Error Correction), pois a correção dos erros é tratada “antecipadamente” enviando-se 
informações extras, ao invés de esperar que os erros aconteçam e tratar deles mais tarde, por meio 
de retransmissão. Técnicas de FEC normalmente são usadas em redes sem fios, como 802.11. 





Seis versões de C(x) são muito usadas nos protocolos da camada de enlace (como mostra a Tabela 2.3). 
Por exemplo, Ethernet usa CRC-32, enquanto HDLC usa CRC-CCITT. O ATM, conforme descrito no 
Capítulo 3, utiliza CRC-8, CRC-10 e CRC-32. 

Finalmente, observamos que o algoritmo de CRC, embora aparentemente complexo, é facilmente 
implementado em hardware usando um registrador de deslocamento de k bits e portas XOR. O nú- 
mero de bits no registrador de deslocamento é igual ao grau do polinômio gerador (k). A Figura 2.16 
mostra o hardware que seria usado para o gerador xº+ x? + 1 do nosso exemplo anterior. A mensagem 
é deslocada para dentro pela esquerda, começando com o bit mais significativo e terminando com a 
sequência de k zeros que é anexada à mensagem, assim como no exemplo da divisão longa. Quando 
todos os bits tiverem sido deslocados para dentro e XORados apropriadamente, o registrador conterá 
o resto — ou seja, o CRC (bit mais significativo na direita). A posição das portas XOR é determinada da 
seguinte forma: se os bits no registrador de deslocamento forem rotulados de 0 até k — 1, da esquerda 
para a direita, então coloque uma porta XOR na frente do bit n se houver um termo x” no polinômio 
gerador. Assim, vemos uma porta XOR na frente das posições 0 e 2 para o gerador x’ + x? +x. 


2.5 Transmissão confiável 


Conforme vimos na seção anterior, os quadros às vezes são corrompidos enquanto estão em trânsito, 
de modo que um código corretor de erros como o CRC pode ser usado para detectar tais erros. Embora 
alguns códigos de erros sejam fortes o suficiente para também corrigir erros, na prática o overhead 
normalmente é muito grande para tratar todos os erros de bit e em rajada que podem ser introduzidos 
em um enlace de rede. Mesmo quando os códigos corretores de erros são usados (por exemplo, em 
enlaces sem fios), alguns erros serão muito graves para serem corrigidos. Como resultado, alguns quadros 
modificados precisam ser descartados. Um protocolo no nível de enlace que deseja entregar quadros de 
modo confiável precisa, de alguma maneira, recuperar-se desses quadros descartados (perdidos). 
Vale a pena observar que a confiabilidade é uma função que pode ser fornecida no nível de enlace, 
mas muitas tecnologias de enlace modernas omitem essa função. Além disso, a entrega confiável 


Tabela 2.3 Polinômios de CRC comuns 





CRC C(x) 

CRC-8 4x 4x +1 

CRC-10 x0 40 40 4X 4x] +41 
CRC-12 x2 4x1, +H] 
CRC-16 x16 + x+ x2+ 1 
CRC-CCITT x6 4x2 4x4 1 


CRC-32 x2 4x6 4x8 4x2. 4x6 4x2 4x0 XO ax EXE X+T 
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Mensagem FIGURA 2.16 Cálculo do CRC usando registrador de deslocamento. 
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frequentemente é fornecida em níveis mais altos, incluindo na camada de transporte (conforme des- 
crito na Seção 5.2) e, às vezes, na camada de aplicação (Capítulo 9). O local onde ela deve ser fornecida 
é um assunto de debate e depende de muitos fatores. Aqui, vamos descrever os fundamentos da en- 
trega confiável, pois os princípios são comuns entre as camadas, mas você deve ficar ciente que não 
estamos falando apenas de uma função da camada de enlace (veja a nota em destaque “O que há em 
uma camada?”, anteriormente neste capítulo, para uma maior discussão sobre isso). 

Isso normalmente é feito usando uma combinação de dois mecanismos fundamentais — confirmações e 
expirações de temporizador (timeouts). Uma confirmação (ou ACK, abreviação do inglês Acknowledgment) 
é um pequeno quadro de controle que um protocolo retorna para o seu par, dizendo que recebeu um 
quadro enviado anteriormente. Com quadro de controle queremos dizer um cabeçalho sem quaisquer 
dados, embora um protocolo possa incluir um ACK em um quadro de dados que esteja enviando na 
direção oposta, usando um mecanismo de carona (piggybacking). O recebimento de uma confirmação 
indica ao emissor do quadro original que seu quadro foi entregue com sucesso. Se o emissor não receber 
uma confirmação após um período de tempo razoável, então ele retransmite o quadro original. Essa ação 
de esperar um período de tempo razoável é chamada de expiração de temporizador (timeout). 

A estratégia geral de usar confirmações e expirações de temporizador para implementar a entrega 
confiável às vezes é chamada de solicitação automática de repetição (normalmente abreviada como 
ARQ - Automatic Repeat Request). Esta seção descreve três algoritmos de ARQ diferentes usando uma 
linguagem genérica; ou seja, não fornecemos informações detalhadas sobre os campos de cabeçalho 
de um protocolo em particular. 


2.5.1 Parar e esperar 


O esquema de ARQ mais simples é o algoritmo parar e esperar (ou stop-and-wait). A ideia da estratégia 
parar e esperar é simples. Depois de transmitir um quadro, o emissor espera uma confirmação antes de 
transmitir o próximo quadro. Se a confirmação não chegar após um período de tempo, um temporizador 
no emissor expira e ele retransmite o quadro original. 

A Figura 2.17 ilustra quatro cenários diferentes que resultam desse algoritmo básico. Essa figura é uma 
linha de tempo, um modo comum de representar o comportamento de um protocolo (veja também a 
nota em destaque sobre esse tipo de diagrama). O lado emissor é representado à esquerda, o lado receptor 
é representado à direita e o tempo flui de cima para baixo. A Figura 2.17(a) mostra a situação em que o ACK é 
recebido antes que o temporizador expire; (b) e (c) mostram a situação em que o quadro originale o ACK, 
respectivamente, são perdidos; e (d) mostra a situação em que o temporizador expira muito cedo. Lembre-se 
de que “perdido” significa que o quadro foi alterado enquanto estava em trânsito, que essa alteração foi 
detectada por um código de erro no receptor e que o quadro foi descartado em consequência disso. 


LINHAS DE TEMPO E DIAGRAMAS DE TROCA DE PACOTES 


As Figuras 2.17 e 2.18 são dois exemplos de uma ferramenta muito utilizada no ensino, explicação e projeto 
de protocolos: a linha de tempo ou o diagrama de troca de pacotes. Você verá muito mais deles neste 
livro — veja um exemplo mais complexo na Figura 9.9. Eles são muito úteis, pois capturam visualmente o 


comportamento de um sistema distribuído ao longo do tempo - algo que pode ser muito difícil de analisar. 
Ao projetar um protocolo, você frequentemente terá que estar preparado para o inesperado — um sistema 
falha, uma mensagem se perde ou algo que você esperava acontecer rapidamente passa a levar muito tempo. 
Esses tipos de diagramas podem nos ajudar a entender o que poderia sair errado nesses casos e, assim, 
ajudar um projetista de protocolos a ficar preparado para cada eventualidade. 
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FIGURA 2.17 Linha de tempo mostrando quatro cenários para o algoritmo parar e esperar. (a) O ACK é recebido antes que 
o temporizador expire; (b) o quadro original é perdido; (c) o ACK é perdido; (d) o temporizador expira muito cedo. 


Há uma sutileza importante no algoritmo parar e esperar. Suponha que o emissor envia um quadro 
e o receptor o confirma, mas a confirmação se perde ou sua chegada demora. Essa situação é ilus- 
trada nas linhas de tempo (c) e (d) da Figura 2.17. Nos dois casos, o temporizador no emissor expira 
e ele retransmite o quadro original, mas o receptor pensará que esse é o próximo quadro, pois ele 
recebeu corretamente e já confirmou o primeiro quadro. Isso pode potencialmente de fazer com que 
cópias duplicadas de um quadro sejam entregues. Para resolver esse problema, o cabeçalho para um 
protocolo parar e esperar normalmente inclui um número de sequência de 1 bit — ou seja, o número 
de sequência pode assumir os valores 0 e 1 — e os números de sequência usados para cada quadro se 
alternam, conforme ilustra a Figura 2.18. Assim, quando o emissor retransmite o quadro 0, o receptor 
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FIGURA 2.18 Linha de tempo para o algoritmo parar e esperar com número de 
sequência de 1 bit. 
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Emissor Receptor FIGURA 2.19 Linha de tempo para o algoritmo de janela deslizante. 


Tempo 








pode determinar que ele está vendo uma segunda cópia do quadro 0, ao invés da primeira cópia do 
quadro 1 e, portanto, pode ignorá-lo (o receptor ainda o confirma, para a eventualidade de o primeiro 
ACK ter se perdido). 

A principal deficiência do algoritmo parar e esperar é que ele permite que o emissor tenha apenas 
um quadro pendente de cada vez no enlace, e isso pode ficar muito abaixo da capacidade do enlace. 
Considere, por exemplo, um enlace de 1,5 Mbps com um tempo de ida e volta de 45 ms. Esse enlace 
tem um produto atraso x largura de banda de 67,5 Kb, ou aproximadamente 8 KB. Como o emissor só 
pode enviar um quadro por RTT, e supondo que um tamanho de quadro seja 1 KB, isso resulta em uma 
taxa de envio máxima de 


Bits por Quadro + Tempo por Quadro 
=1024x8-0,045 
=182 kbps 


ou cerca de um oitavo da capacidade do enlace. Para usar o enlace totalmente, então, gostaríamos que 
o emissor pudesse transmitir até oito quadros antes de ter que esperar uma confirmação. 


O significado do produto atraso x largura de banda é que ele representa a quantidade de dados que poderiam 
estar em trânsito. Gostaríamos de poder enviar todos esses dados sem esperar pela primeira confirmação. O 


princípio em questão aqui normalmente é conhecido como manter o tubo cheio. Os algoritmos apresentados 
nas duas próximas subseções fazem exatamente isso. 





2.5.2 Janela deslizante 


Considere novamente o cenário em que o enlace tem um produto atraso X largura de banda de 8 KB e 
os quadros possuem um tamanho de 1 KB. Gostaríamos que o emissor estivesse pronto para transmitir 
o nono quadro praticamente no mesmo instante em que o ACK para que o primeiro quadro chegasse. O 
algoritmo que nos permite fazer isso é chamado de janela deslizante, e uma linha de tempo ilustrativa 
aparece na Figura 2.19. 


O algoritmo de janela deslizante 

O algoritmo de janela deslizante funciona da seguinte maneira: primeiro, o emissor atribui um número de 
sequência, indicado como SegNum (Sequence Number), para cada quadro. Por enquanto, vamos ignorar 
o fato de que o SegNum é implementado por um campo de cabeçalho de tamanho finito e, em vez disso, 
considerar que ele pode crescer infinitamente. O emissor mantém três variáveis: o tamanho da janela 
de envio, indicado como SWS (Send Window Size), refere-se ao limite máximo do número de quadros 
pendentes (não confirmados) que o emissor pode transmitir; LAR (Last Acknowledgment Received) indica 
o número de sequência da última confirmação recebida; e LFS (Last Frame Sent) indica o número de 
sequência do último quadro enviado. O emissor também mantém constante a seguinte relação: 


LFS-LAR <SWS 
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< SWS FIGURA 2.20 Janela deslizante no emissor. 


< RWS FIGURA 2.21 Janela deslizante no receptor. 


t t 


LFR LAF 


Essa situação é ilustrada na Figura 2.20. 

Quando uma confirmação chega, o emissor move o LAR para a direita, permitindo assim que o 
emissor transmita outro quadro. Além disso, o emissor associa um temporizador a cada quadro que 
transmite, e retransmite o quadro se o temporizador expirar antes que um ACK seja recebido. Observe 
que o emissor precisa estar disposto a armazenar até SWS quadros, pois precisa estar preparado para 
retransmiti-los até que sejam confirmados. 

O receptor mantém as três variáveis a seguir: o tamanho da janela de recepção, indicado por RWS 
(Receive Window Size), indica o limite superior do número de quadros fora de ordem que o receptor 
está disposto a aceitar; LAF (Largest Acceptable Frame) indica o número de sequência do maior quadro 
aceitável; e LFR (Last Frame Received) indica o número de sequência do último quadro recebido. O 
receptor também mantém constante o seguinte: 


LAF-LFR < RWS 

Essa situação é ilustrada na Figura 2.21. 

Quando um quadro com número de sequência SeqNum chega, o receptor toma a seguinte ação. Se 
SeqNum < LFR ou SeqNum > LAF, então o quadro está fora da janela do receptor e é descartado. Se 
LFR < SeqNum < LAF então o quadro está dentro da janela do receptor e é aceito. Agora o receptor precisa 
decidir se enviará ou não um ACK. Considere que SeqNumToAck indica o maior número de sequência 
ainda não confirmado, de modo que todos os quadros com números de sequência menores ou iguais 
a SeqNumToAck foram recebidos. O receptor confirma o recebimento de SeqNumToAck, mesmo que 
pacotes com números mais altos tenham sido recebidos. Essa confirmação é considerada cumulativa. 
Depois ele ajusta LFR = SegNumToAck e ajusta LAF = LFR + RWS. 

Por exemplo, suponha que LFR=5 (ou seja, o último ACK que o receptor enviou foi para o número 
de sequência 5) e RWS =4. Isso significa que LAF =9. Se os quadros 7 e 8 chegarem, eles serão mantidos 
em buffer, pois estão dentro da janela do receptor. Porém, nenhum ACK precisa ser enviado, pois o 
quadro 6 ainda está por chegar. Dizemos que os quadros 7 e 8 chegaram fora da ordem. (Tecnicamente, 
o receptor poderia reenviar um ACK para o quadro 5 quando os quadros 7 e 8 chegarem.) Se o quadro 
6 chegar depois — talvez ele esteja atrasado porque foi perdido na primeira vez e teve que ser retrans- 
mitido, ou talvez ele simplesmente sofreu atrasos! —, o receptor confirma o quadro 8, aumenta LFR para 
8 e ajusta LAF para 12. Se o quadro 6 foi realmente perdido, então um temporizador terá expirado no 
emissor, fazendo com que ele retransmita o quadro 6. 

Observamos que, quando um temporizador expira, a quantidade de dados em trânsito diminui, 
pois o emissor é incapaz de avançar sua janela até que o quadro 6 seja confirmado. Isso significa que, 
quando ocorrem perdas de pacote, esse esquema não está mais mantendo o tubo cheio. Quanto mais 
tempo levar para se perceber que houve uma perda de pacote, mais grave se torna esse problema. 

Observe que, neste exemplo, o receptor poderia ter enviado uma confirmação negativa (NAK — 
Negative Acknowledgment) para o quadro 6 assim que o quadro 7 chegasse. Porém, isso é desnecessário 
porque o mecanismo de expiração de temporizador do emissor é suficiente para cobrir essa situação, 


“É improvável que um pacote possa ser atrasado dessa maneira em um enlace ponto a ponto, porém, mais adiante, 
veremos esse mesmo algoritmo sendo usado em redes mais complexas, nas quais esses atrasos são possíveis. 
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e enviar NAKs aumenta a complexidade do receptor. Além disso, como já dissemos, teria sido possível 
enviar confirmações adicionais do quadro 5 quando os quadros 7 e 8 chegassem; em alguns casos, um 
emissor pode usar ACKs duplicados como uma dica de que um quadro foi perdido. As duas técnicas 
ajudam a melhorar o desempenho, permitindo a detecção antecipada de perdas de pacote. 

Ainda outra variação desse esquema seria usar confirmações seletivas. Ou seja, o receptor poderia 
confirmar exatamente os quadros que recebeu, ao invés de apenas o quadro de número mais alto rece- 
bido em ordem. Assim, no exemplo anterior, o receptor poderia confirmar o recebimento dos quadros 
7 e 8. Dar mais informações ao emissor torna potencialmente mais fácil para ele manter o tubo cheio, 
mas aumenta a complexidade da implementação. 

O tamanho da janela de envio é selecionado de acordo com quantos quadros queremos ter pendentes 
no enlace em determinado momento; o valor de SWS é fácil de calcular para um determinado produto 
atraso X largura de banda.º Entretanto, o receptor pode fixar RWS com o valor que quiser. Dois valores 
comuns são RWS = 1, significando que o receptor não manterá em buffer quadro algum que chegue fora 
de ordem, e RWS=SWS, que significa que o receptor pode manter em buffer qualquer um dos quadros 
que o emissor transmitir. Não faz sentido fazer RWS > SWS, pois é impossível que mais do que SWS 
quadros cheguem fora de ordem. 


Números de sequência finitos e janela deslizante 

Agora, vamos voltar à simplificação que apresentamos no algoritmo — nossa suposição de que os números 
de sequência podem crescer infinitamente. Na prática, é claro, o número de sequência de um quadro é 
especificado em um campo do cabeçalho que possui algum tamanho finito. Por exemplo, um campo de 
três bits significa que existem oito números de sequência possíveis, 0 ... 7. Isso faz com que seja necessário 
reutilizar os números de sequência ou, em outras palavras, os números de sequência se reiniciam ciclica- 
mente. Isso faz surgir o problema de ser necessário distinguir entre diferentes ocorrências dos mesmos 
números de sequência, o que significa que a quantidade de números de sequência possíveis precisa ser 
maior do que o número de quadros que podem ficar pendentes. Por exemplo, o esquema parar e esperar 
permitia um quadro pendente de cada vez e tinha dois números de sequência distintos. 

Suponha que tenhamos um número a mais em nosso espaço de números de sequência do que a 
quantidade de quadros potencialmente pendentes; ou seja, que SWS < MaxSegNum - 1, onde Max- 
SeqNum é a quantidade de números de sequência disponíveis. Isso é suficiente? A resposta depende de 
RWR. Se RWS = 1, então MaxSegNum > SWS +1 é suficiente. Se RWS é igual a SWS, então ter um valor 
de MaxSegNum igual o tamanho da janela de envio mais 1 não é o suficiente. Para ver isso, considere 
a situação em que temos os oito números de sequência de 0 até 7, e SWS=RWS=7. Suponha que o 
emissor transmita os quadros 0 ... 6 e que eles são recebidos com sucesso, mas os ACKs se perdem. O 
receptor agora está esperando os quadros 7, O... 5, mas o temporizador do emissor expira e ele reenvia 
os quadros O... 6. Infelizmente, o receptor está esperando a segunda ocorrência dos quadros 0... 5, mas 
recebe a primeira ocorrência desses quadros. É exatamente esta a situação que queremos evitar. 

Acontece que o tamanho da janela de envio não pode ser maior que metade da quantidade de 
números de sequência disponíveis quando RWS = SWS ou, escrito de uma forma mais precisa: 


SWS <(MaxSeqNum-+1)/2 


Intuitivamente, o que isso está dizendo é que o protocolo de janela deslizante alterna entre as duas 
metades do espaço de números de sequência, assim como o esquema parar e esperar alterna entre os 
números de sequência 0 e 1. A única diferença é que ele se desloca continuamente entre as duas metades, 
ao invés de alternar discretamente entre elas. 

Observe que essa regra é específica à situação em que RWS = SWS. Deixamos como um exercício ao 
leitor determinar a regra mais geral que funciona para quaisquer valores de RWS e SWS. Observe também 
que a relação entre o tamanho da janela e o espaço de números de sequência depende da suposição que 
é tão óbvia pode facilmente passar desapercebida, a saber, que os quadros não são reordenados em 
trânsito. Isso não pode acontecer em um enlace ponto a ponto direto, pois não existe forma de um 


“Quer dizer, é fácil se soubermos o atraso e a largura de banda, mas, às vezes, não sabemos, e sua estimativa correta é um 
desafio para os projetistas de protocolos. Discutimos isso com mais detalhes no Capítulo 5. 
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quadro ultrapassar outro durante a transmissão. Porém, no Capítulo 5 veremos o algoritmo de janela 
deslizante usado em um ambiente diferente, e precisaremos criar outra regra. 


Implementação da janela deslizante 
As rotinas a seguir ilustram como poderíamos implementar os lados emissor e receptor do algoritmo 
de janela deslizante. As rotinas são tomadas de um protocolo funcional chamado, de modo bastante 
apropriado, protocolo de janela deslizante (SWP - Sliding Window Protocol). Para não nos preocuparmos 
com os protocolos adjacentes no grafo de protocolos, denotamos o protocolo que fica acima do SWP 
como o protocolo de alto nível (HLP — High-Level Protocol) e o protocolo que fica abaixo do SQP como 
o protocolo de nível de enlace (LLP — Link-Level Protocol). 

Começamos definindo um par de estruturas de dados. Primeiro, o cabeçalho do quadro é muito 
simples: ele contém um número de sequência (SegNum) e um número de confirmação (AckNum). Ele 
também contém um campo Flags que indica se o quadro é um ACK ou se transporta dados. 


typedef u_char SwpSeqgno; 


typedef struct { 

SwpSeqno SeqNum; /* número seq. deste quadro */ 
eqno AckNum; /* ack do quadro recebido */ 
u_char Flags; /* até 8 bits de marcadores */ 

} SwpHdr; 








Em seguida, o estado do algoritmo de janela deslizante tem a seguinte estrutura. Para o lado emissor 
do protocolo, esse estado inclui as variáveis LAR e LFS, conforme descrito anteriormente nesta seção, 
além de uma fila que mantém quadros que foram transmitidos mas ainda não confirmados (sendQ). 
O estado emissor também inclui um semáforo de contagem chamado sendWindowNotFull. Veremos 
como isso é usado a seguir, mas geralmente um semáforo é uma primitiva de sincronização que admite 
as operações semWait e semSignal. Cada chamada de semSignal incrementa o semáforo em 1, e cada 
chamada de semWait decrementa s em 1, com o processo chamador sendo bloqueado (suspenso) se 
o processo de decrementar o semáforo fizer com que seu valor fique menor que 0. Um processo que é 
bloqueado durante sua chamada a semWait terá permissão para retomar sua execução assim que ope- 
rações semSignal suficientes tenham sido realizadas para elevar o valor do semáforo acima de 0. 

Para o lado receptor do protocolo, o estado inclui a variável NFE (Next Frame Expected). Esse é o 
próximo quadro esperado, o quadro com um número de sequência um a mais do que o último quadro 
recebido (LFR), descrito anteriormente nesta seção. Há também uma fila que armazena quadros que fo- 
ram recebidos fora de ordem (recvQ). Finalmente, embora não sejam mostrados, os tamanhos das janelas 
deslizantes do emissor e do receptor são definidos por constantes SWS e RWS, respectivamente. 


Eu ey 


último ACK 






> LFS; /* último quadro enviado */ 
re sendWindowNotFull; 
lho pré-inicializado */ 





slot { 
imeout; /* evento associado à expiração do 
dor de envio */ 
sg msg; 
} sendQ[SWS] ; 


/* do do lado receptor: */ 








pSegno NFE; /* seqno do próximo quadro 
rado */ 
struct recvQ slot 1 


ved; /* msg é válida? */ 





O lado emissor do SWP é implementado pelo procedimento sendSWP. Essa rotina é bem simples. 
Primeiro, semWait faz com que esse processo seja bloqueado em um semáforo até que seja permitido 
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enviar outro quadro. Quando tiver permissão para prosseguir, sendSWP ajusta o número de sequência 
no cabeçalho do quadro, salva uma cópia do quadro na fila de transmissão (sendQ), programa um evento 
de expiração de temporizador para tratar o caso em que o quadro não é confirmado e envia o quadro 
para o protocolo no próximo nível mais baixo da pilha de protocolos, que denotamos por LINK. 

Um detalhe que precisa ser observado é a chamada a store swp hdr imediatamente antes da cha- 
mada a msgAddHdr. Essa rotina traduz a estrutura C que contém o cabeçalho do SWP (state-> hdr) em 
uma sequência de bytes que possa ser seguramente anexada ao início da mensagem (hbuf). Essa rotina 
(que não é mostrada) precisa traduzir cada campo inteiro do cabeçalho para a ordem de bytes da rede 
e remover qualquer preenchimento que o compilador tenha acrescentado à estrutura em C. A questão 
da ordem de bytes é discutida de modo mais completo na Seção 7.1, mas por enquanto é suficiente 
considerar que essa rotina coloca o bit mais significativo de um número inteiro composto por múltiplas 
palavras no byte com o endereço mais alto. 

Outro fator de complexidade nessa rotina é o uso de semWait e do semáforo sendWindowNotFull. 
sendWindowNotFull é inicializado com o tamanho da janela deslizante do emissor, SWS (essa inicializa- 
ção não é mostrada). Toda vez que o emissor transmite um quadro, a operação semWait decrementa esse 
contador e bloqueia o emissor se a contagem chegar a 0. Toda vez que um ACK é recebido, a operação 
semSignal chamada em deliverSWP (veja a seguir) incrementa esse contador, desbloqueando assim 
qualquer emissor esperando. 


static int 
sendSwP (SwpState “state, Msg *frame) 
{ 

struct sendQ slot 


hbuf [HLEN] ; 









state->LFS; 
ate->hdr.SeqNum % SWS]; 








7 > hdr(state->hdr, hbuf); 
msgAddHdr (frame, hbuf, HLEN); 

J; frame); 

hedule (swpTimeout, slot, 








SEND TIMEOUT); 
return send(LINK, frame); 


Antes de continuar com o lado receptor do SWP precisamos sanar uma aparente inconsistência. 
Por um lado, dissemos que um protocolo de alto nível invoca os serviços de um protocolo de baixo 
nível chamando a operação send, de modo que esperaríamos que um protocolo que queira enviar 
uma mensagem via SWP chame send(SWP, packet). Por outro lado, o procedimento que implementa 
a operação de envio do SQP é chamado sendSWP, e seu primeiro argumento é uma variável de estado 
(SwpState). O que isso significa? A resposta é que o sistema operacional fornece o código colante que 
traduz a chamada genérica a send em uma chamada específica de protocolo a sendSWP. Esse código 
colante mapeia o primeiro argumento de send (a variável de protocolo mágica SWP) em um ponteiro 
de função para sendSWP e um ponteiro para o estado de protocolo que SWP precisa para realizar seu 
trabalho. O motivo para termos o protocolo de alto nível chamando indiretamente a função específica 
do protocolo por meio da chamada de função genérica é que queremos limitar quanta informação de 
código o protocolo de alto nível tem relativo ao protocolo de baixo nível. Isso facilita a mudança da 
configuração do grafo de protocolos em alguma ocasião no futuro. 

Agora, vamos passar para a implementação específica do protocolo SWP da operação deliver, que é 
dada no procedimento deliverSWP. Essa rotina, na realidade, trata de dois tipos diferentes de mensagens 
que chegam: ACKs para quadros enviados anteriormente por esse nó e quadros de dados que chegam 
nesse nó. De certa forma, a metade relativa ao ACK dessa rotina é o correspondente do lado emissor 
do algoritmo usado em sendSWP. Uma decisão quanto a se a mensagem que chega é um ACK ou um 
quadro de dados é feita verificando o campo Flags no cabeçalho. Observe que essa implementação 
em particular não permite o uso do mecanismo de carona para transportar um ACK juntamente com 
quadros de dados. 
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Quando o quadro que chega contém um ACK, deliverSWP simplesmente encontra uma posição 
(slot) na fila de transmissão (sendQ) que corresponde ao ACK, cancela o evento de expiração do tem- 
porizador e libera o quadro salvo nessa posição. Esse trabalho, na realidade, é feito em um laço, pois o 
ACK pode ser cumulativo. A única outra coisa a observar a respeito desse caso é a chamada à sub-rotina 
swpInWindow. Essa sub-rotina, que é dada a seguir, garante que o número de sequência para o quadro 
sendo confirmado está dentro do intervalo de ACKs que o emissor atualmente espera receber. 

Quando o quadro que chega contém dados, deliverSWP primeiro chama msgStripHdr e load swp hdr 
para extrair o cabeçalho do quadro. A rotinaload swp hdr é a correspondente de store swp hdr discutida 
anteriormente; ela traduz uma cadeia de bytes na estrutura de dados em C que contém o cabeçalho SWP. 
deliverSWP, então, chama swpInWindow para garantir que o número de sequência do quadro esteja dentro 
do intervalo de números de sequência que ele espera. Se estiver, a rotina percorre todo o conjunto de qua- 
dros consecutivos que recebeu e os passa para o protocolo de nível superior chamando a rotina deliverHLP. 
Ele também envia um ACK cumulativo de volta ao emissor, mas faz isso percorrendo a fila de recebimento 
(ele não usa a variável SegNumToAck usada na descrição dada anteriormente nesta seção). 


static int 
deliverSWP (SwpState state, Msg *frame) 

{ 

SwpHdr hdr; 

char *hbuf; 

hbuf = msgStripHdr (frame, HLEN); 

load swp hdr(&hdr, hbuf) 

if (hdr->Flags & FLAG ACK VALID) 

{ 

/* recebida confirmação---lado EMISSOR */ 
if (swpInWindow(hdr.AckNum, state->LAR + 1, 
state->LFS)) 


t 

do 

t 

struct sendQ slot *slot; 

slot = &state->sendQ[++state->LAR % SWS]; 







evCancel (slot 
msgDestroy (&slot 


imeout); 
sg); 








semSignal (&stat >sendWi ndowNot Full); 

} while (state->LAR != hdr.AckNum) ; 

} 

} 

if (hdr.Flags & FLAG HAS DATA) 

{ 

struct recvQ slot “slot; 

/* pacote de dadc recebido---lado RECEPTOR */ 





slot = &state-> Q[lhdr.SegqNum % RWS]; 
if (!swpInWindow(hdr.SegqNum, state->NFE, 


state->NFE + RWS - 1)) 





/* remove a mensagem */ 
return SUCCESS; 


gSaveCopy (&slot->msg 








slot->r ived = TRUE; 

if (hdr.SeqNum == state->NFE) 
{ 

Msg m; 


while (slot->received) 






{ 

deliver(HLP, &slot->msg); 

m >y (&slot->msg) ; 

slot eceived = FALSE; 

slot = &state->recvQ[+tstate->NFE $% RWS]; 


} 

/* envia ACK: */ 

prepare_ack(&m, state->NFE - 1); 
send (LINK, &m); 

msgDestroy(ém); 

} 

} 


return SUCCESS; 
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Finalmente, swpInWindow é uma sub-rotina simples, que verifica se determinado número de 
sequência se encontra entre algum número de sequência mínimo e máximo. 


static boo 
swpInWind 





(SwpSeqno seqno, SwpSeqno min, SwpSeqno max) 


OS maxpos; 


/* 





» — min; -~ no intervalo [0..MAX) */ 


no intervalo [0..MAX] */ 






ma s = max - min 
return pos < max 


} 





Ordem dos quadros e controle de fluxo 

O protocolo de janela deslizante talvez seja o algoritmo mais conhecido nas redes de computadores. 
Porém, o que é facilmente confuso a respeito do algoritmo é que ele pode ser usado para servir a três 
papéis diferentes. O primeiro papel é aquele no qual nos concentramos nesta seção — entregar quadros 
de modo confiável por um enlace não confiável. (Em geral, o algoritmo pode ser usado para entregar 
mensagens de modo confiável por uma rede não confiável.) Essa é a função básica do algoritmo. 

O segundo papel ao qual o algoritmo de janela deslizante pode servir é preservar a ordem em que 
os quadros são transmitidos. Isso é fácil de fazer no receptor - como cada quadro tem um número de 
sequência, o receptor simplesmente garante que não passará um quadro para o protocolo do próximo 
nível mais alto até que já tenha passado todos os quadros com um número de sequência menor. Ou 
seja, o receptor mantém em buffer (isto é, não passa adiante) os quadros fora de ordem. A versão do 
algoritmo de janela deslizante descrita nesta seção preserva a ordem do quadro, embora pudéssemos 
imaginar uma variação em que o receptor passa quadros para o próximo protocolo sem esperar que 
todos os quadros anteriores sejam entregues. Uma pergunta que devemos nos fazer é se realmente 
precisamos do protocolo de janela deslizante para manter os quadros em ordem ou se, em vez disso, 
essa é uma funcionalidade desnecessária no nível de enlace. Infelizmente, ainda não vimos o suficiente 
da arquitetura das redes para responder a essa pergunta; primeiro, precisamos entender como uma 
sequência de enlaces ponto a ponto é conectada por switches para formar um caminho fim a fim. 

O terceiro papel que o algoritmo de janela deslizante às vezes desempenha é dar suporte ao controle 
de fluxo — um mecanismo de feedback pelo qual o receptor é capaz de regular o emissor. Esse mecanismo 
é usado para evitar que o emissor sobrecarregue o receptor —, ou seja, transmitir mais dados do que o 
receptor é capaz de processar. Isso normalmente é feito expandindo o protocolo de janela deslizante de 
modo que o receptor não apenas confirme os quadros que recebeu, mas também informe ao emissor 
quantos quadros ele tem espaço para receber. O número de quadros que o receptor é capaz de receber 
corresponde a quanto espaço livre em buffer ele possui. Assim como no caso da entrega ordenada, 
precisamos ter certeza de que o controle de fluxo é necessário no nível de enlace antes de incorporá-lo 
ao protocolo de janela deslizante. 


Um conceito importante a ser lembrado desta discussão é o princípio de projeto de sistemas que chamamos 
de separação de interesses. Ou seja, você precisa ter o cuidado de distinguir entre diferentes funções que às 
vezes são reunidas em um mecanismo, e garantir que cada função é necessária e está sendo suportada pelo 
método mais eficaz. Nesse caso em particular, a entrega confiável, a entrega ordenada e o controle de fluxo às 


vezes são combinados em um único protocolo de janela deslizante, e devemos nos perguntar se essa é a coisa 
certa a fazer no nível de enlace. Com essa pergunta em mente, retornaremos ao algoritmo de janela deslizante 
no Capítulo 3 (mostramos como as redes X.25 o utilizam para implementar o controle de fluxo salto a salto) 
e no Capítulo 5 (descrevemos como o TCP o utiliza para implementar um canal de fluxo de bytes confiável). 





2.5.3 Canais lógicos concorrentes 


O protocolo de enlace de dados usado na ARPANET oferece uma alternativa interessante para o protocolo 
de janela deslizante, no sentido que ele é capaz de manter o tubo cheio enquanto ainda usa o algoritmo 





Capítulo 2 * Conectando-se 73 
ES 
ELSEVIER 


parar e esperar simples. Uma consequência importante dessa técnica é que os quadros enviados por 
determinado enlace não são mantidos em qualquer ordem específica. O protocolo também não indica 
nada sobre controle de fluxo. 

A ideia por trás do protocolo ARPANET, a que nos referimos como canais lógicos concorrentes, é 
multiplexar vários canais lógicos em um único enlace ponto a ponto e executar o algoritmo parar e 
esperar em cada um desses canais lógicos. Nenhuma relação é mantida entre os quadros enviados em 
qualquer um dos canais lógicos, mas como um quadro diferente pode estar pendente em cada um dos 
vários canais lógicos, o emissor pode manter o enlace ocupado. 

Mais precisamente, o emissor mantém 3 bits de estado para cada canal: um booleano, dizendo se 
o canal está atualmente ocupado; o número de sequência de 1 bit para usar da próxima vez que um 
quadro for enviado nesse canal lógico; e o próximo número de sequência esperado em um quadro que 
chega nesse canal. Quando o nó tem um quadro para enviar, ele usa o canal ocioso mais baixo e, exceto 
por isso, se comporta exatamente como o esquema parar e esperar. 

Na prática, a ARPANET admitia 8 canais lógicos por cada enlace terrestre e 16 por cada enlace 
de satélite. No caso do enlace terrestre, o cabeçalho para cada quadro incluía um número de canal de 
3 bits e um número de sequência de 1 bit, formando um total de 4 bits. Esse é exatamente o número 
de bits que o protocolo de janela deslizante exige para dar suporte a 8 quadros pendentes no enlace 
quando RWS=SWS. 


2.6 Ethernet e redes de acesso múltiplo (802.3) da, 


LAB 01: 

CSMA 
Desenvolvido em meados da década de 1970 pelos pesquisadores do Xerox Palo Alto Research Cen- 
ter (PARC), o Ethernet em certo momento tornou-se a tecnologia preponderante para redes locais, 
destacando-se dentre um conjunto considerável de tecnologias concorrentes. Hoje, ele compete 
principalmente com as redes sem fio 802.11, mas continua sendo extremamente popular em redes de 
universidades e centros de processamento de dados. O nome mais genérico para a tecnologia por trás 
do Ethernet é Acesso Múltiplo com Detecção de Portadora e Detecção de Colisão (Carrier Sense, Multiple 
Access with Collision Detect - CSMA/CD). 

Conforme indicado pelo nome CSMA, o Ethernet é uma tecnologia de rede de acesso múltiplo, 
significando que um conjunto de nós envia e recebe quadros por um enlace compartilhado. Portanto, 
você pode pensar no Ethernet como sendo uma espécie de ônibus que possui várias estações ligadas 
a ele. No CSMA/CD, o termo detecção de portadora (“carier sense”) significa que todos os nós podem 
distinguir entre um enlace ocioso e ocupado, e a detecção de colisão (“collision detect”) significa que um 
nó escuta enquanto transmite e, portanto, pode detectar quando um quadro que ele está transmitindo 
interferiu (colidiu) com um quadro transmitido por outro nó. 

O Ethernet tem suas origens na primeira rede de pacotes por rádio, chamada Aloha, desenvolvida na 
Universidade do Havaí para realizar a comunicação de computadores entre as ilhas havaianas. Assim 
como a rede Aloha, o problema fundamental enfrentado pelo Ethernet é como mediar o acesso a um 
meio compartilhado de forma justa e eficiente (no Aloha, o meio era a atmosfera, enquanto no Ethernet 
o meio é um cabo coaxial). A ideia básica no Aloha e no Ethernet é um algoritmo que controla quanto 
cada nó pode transmitir. 

É interessante que os enlaces Ethernet modernos agora são, em grande parte, ponto a ponto; ou seja, 
eles conectam um host a um switch ethernet, ou então interconectam switches. Logo, as técnicas de 
“acesso múltiplo” não são muito usadas nas redes Ethernet de hoje. Ao mesmo tempo, as redes sem fios 
se tornaram extremamente populares, de modo que as tecnologias de acesso múltiplo que começaram 
no Aloha novamente são usadas hoje principalmente em redes sem fios, como nas redes 802.11 (Wi-Fi). 
Essas redes serão discutidas na Seção 2.7. 

Discutiremos os switches Ethernet no próximo capítulo. Por enquanto, vamos nos concentrar na 
forma como um único enlace Ethernet funciona. E embora o Ethernet com acesso múltiplo esteja 
se tornando mais uma curiosidade histórica, os princípios das redes de acesso múltiplo continuam 
a ser importantes o bastante para justificar uma discussão mais aprofundada, que fornecemos a 
seguir. 
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f Transceptor FIGURA 2.22 Transceptor e adaptador Ethernet. 


Cabo Ethernet 
/ Adaptador 


Host 


A Digital Equipment Corporation (DEC) e a Intel Corporation se juntaram à Xerox para definir um 
padrão Ethernet de 10 Mbps em 1978. Esse padrão, então, formou a base para o padrão IEEE 802.3, que 
além disso define uma coleção muito maior de meios físicos sobre os quais uma rede Ethernet pode 
operar, incluindo as versões de 100 Mbps, 1 Gbps e 10 Gbps. 


2.6.1 Propriedades físicas 


Os segmentos Ethernet eram implementados originalmente usando cabo coaxial com comprimento 
de até 500 m. (As redes Ethernet modernas usam pares de fio de cobre trançados, normalmente 
um tipo em particular conhecido como “Categoria 5”,º ou fibras óticas, e em alguns casos podem 
ter muito mais do que 500 m.) Esse cabo era semelhante ao tipo usado para TV a cabo. Os hosts 
se conectavam a um segmento Ethernet por uma conector especial. Um transceptor, um pequeno 
dispositivo conectado diretamente ao conector, detectava quando a linha estava ociosa e con- 
trolava o sinal quando o host estivesse transmitindo. Ele também recebia os sinais que chegavam. 
O transceptor, por sua vez, se conectava a um adaptador Ethernet, que era conectado ao host. Essa 
configuração aparece na Figura 2.22. 

Vários segmentos Ethernet podem ser interligados por meio de repetidores. Um repetidor é um 
dispositivo que encaminha sinais digitais, semelhante ao modo como um amplificador encaminha 
sinais analógicos. Os repetidores entendem apenas bits, e não quadros; porém, não mais do que quatro 
repetidores poderiam ser posicionados entre qualquer par de hosts, significando que uma rede Ethernet 
clássica tinha um alcance total de apenas 2.500 m. Por exemplo, usar apenas dois repetidores entre 
qualquer par de hosts permitiria uma configuração semelhante à que é ilustrada na Figura 2.23 — ou 
seja, um segmento percorrendo a espinha dorsal de um prédio ligado a um segmento em cada andar. 

Também é possível criar um repetidor de múltiplos caminhos, às vezes chamado de hub, conforme 
ilustra a Figura 2.24. Um hub apenas repete, em todas as suas outras portas, aquilo que escuta em uma 
porta. 

Qualquer sinal colocado na rede Ethernet por um host é transmitido por broadcast à rede inteira, ou 
seja, o sinal é propagado nas duas direções, e os repetidores e hubs encaminham o sinal por todos os 
segmentos de saída. Terminadores conectados ao final de cada segmento absorvem o sinal e evitam que 
ele retorne e interfira com os sinais posteriores. As especificações Ethernet originais usavam o esquema 
de codificação Manchester, descrito na Seção 2.2, enquanto a codificação 4B/5B ou o esquema 8B/10B 
semelhante são usados hoje em redes Ethernet de maior velocidade. 

É importante entender que, não importando se determinada rede Ethernet cobre um único segmento, 
uma sequência linear de segmentos conectados por repetidores ou vários segmentos conectados em 
uma configuração estrela por meio de um hub, os dados transmitidos por qualquer host nessa rede 
Ethernet alcançam todos os outros hosts. Essa é a boa notícia. A má notícia é que todos esses hosts estão 
competindo pelo acesso ao mesmo enlace e, por conseguinte, eles são considerados como estando no 


São também mais populares os cabos de “Categoria 6”, sucessores dos cabos de “Categoria 5”. As melhorias de cada nova 
versão incluem maior resistência física e a ruído, o que permite maiores velocidades de transmissão mas também leva a um 
ligeiro aumento de custo (da ordem de 30%). (N.T.) 





Capítulo 2* Conectando-se 75 
r lies 
ELSEVIER 


FIGURA 2.23 Repetidor Ethernet. 
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FIGURA 2.24 Hub Ethernet. FIGURA 2.25 Formato do quadro Ethernet. 


mesmo domínio de colisão. A parte de acesso múltiplo do Ethernet consiste em lidar com a competição 
pelo enlace que surge em um domínio de colisão. 


2.6.2 Protocolo de acesso 


Agora, vamos voltar nossa atenção para o algoritmo que controla o acesso ao enlace Ethernet comparti- 
lhado. Esse algoritmo normalmente é chamado de controle de acesso ao meio (MAC — Media Access 
Control) da rede Ethernet. Ele pode ser implementado no hardware do adaptador de rede. Não vamos 
descrever o hardware em si, mas vamos nos concentrar no algoritmo que ele implementa. Primeiro, 
porém, temos que descrever o formato de quadro e os endereços na rede Ethernet. 


Formato de quadro 

Cada quadro Ethernet é definido pelo formato representado na Figura 2.25.” O preâmbulo de 64 bits 
permite que o receptor seja sincronizado com o sinal; ele é uma sequência de Os e 1s alternados. Os 
hosts de origem e de destino são identificados cada um com um endereço de 48 bits. O campo de 
tipo de pacote serve como uma chave de demultiplexação; ele identifica para qual dos possivelmente 
muitos protocolos de nível superior esse quadro deverá ser entregue. Cada quadro contém até 1.500 
bytes de dados. No mínimo, um quadro deverá conter 46 bytes de dados, mesmo que isso signifique 
que o host precisa preencher o quadro com bits de enchimento (padding) antes de transmiti-lo. O 
motivo para esse tamanho mínimo de quadro é que o quadro precisa ser grande o suficiente para que 
seja possível detectar uma colisão; discutimos isso melhor mais adiante. Finalmente, cada quadro 
inclui um CRC de 32 bits. Assim como o protocolo HDLC descrito na Seção 2.3.2, o Ethernet é um 
protocolo de enquadramento orientado a bits. Observe que, do ponto de vista do host, um quadro 
Ethernet tem um cabeçalho de 14 bytes: dois endereços de 6 bytes e um campo de tipo de 2 bytes. 


"Esse formato de quadro é aquele do padrão Digital-Intel-Xerox; a versão 802.3 é ligeiramente diferente. 
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O adaptador do emissor insere o preâmbulo e o CRC antes de transmitir o quadro, e o adaptador do 
receptor os remove. 


Endereços 

Cada host em uma rede Ethernet — na verdade, cada host Ethernet do mundo inteiro — possui um ende- 
reço Ethernet exclusivo. Tecnicamente, o endereço pertence ao adaptador, e não ao host; normalmente, 
ele é programado de forma permanente na ROM. Os endereços Ethernet normalmente são impressos 
em uma forma que os humanos possam ler, como uma sequência de seis números separados por 
sinais de dois pontos. Cada número corresponde a 1 byte do endereço de 6 bytes e é dado por um par 
de dígitos hexadecimais, um para cada uma das metades de byte (nibbles) de 4 bits; os Os à esquerda 
podem ser omitidos. Por exemplo, 8:0:2b:e4:b1:2 é a representação legível para os humanos do endereço 
Ethernet 


00001000 00000000 0010101111100100 10110001 00000010 


Para garantir que cada adaptador receberá um endereço exclusivo, cada fabricante de dispositivos 
Ethernet recebe um prefixo diferente que precisa ser acrescentado no início do endereço de cada 
adaptador que eles produzem. Por exemplo, a Advanced Micro Devices (AMD) recebeu o prefixo de 
24 bits x080020 (ou 8:0:20). Assim, cada fabricante tem a responsabilidade de garantir que os sufixos 
de endereço que ele produz sejam exclusivos. 

Cada quadro transmitido em uma rede Ethernet é recebido por cada adaptador conectado a essa 
rede. Cada adaptador reconhece aqueles quadros endereçados ao seu endereço e passa apenas esses 
quadros para o host. (Um adaptador também pode ser programado para trabalhar no modo promíscuo, 
no qual entregará todos os quadros recebidos ao host, mas esse não é o modo normal.) Além desses 
endereços de unicast, um endereço Ethernet consistindo em todos os bits 1 é tratado como um endereço 
de broadcast; todos os adaptadores passam para o host os quadros endereçados ao endereço de broad- 
cast. De modo semelhante, um endereço que tem o primeiro bit fixado em 1, mas não é o endereço de 
broadcast, é denominado endereço de multicast. Determinado host pode programar seu adaptador para 
aceitar algum conjunto de endereços de multicast. Os endereços de multicast são usados para enviar 
mensagens para algum subconjunto dos hosts em uma rede Ethernet (por exemplo, todos os servidores 
de arquivos). Resumindo, um adaptador Ethernet recebe todos os quadros e aceita 


e Quadros endereçados ao seu próprio endereço 

e Quadros endereçados ao endereço de broadcast 

e Quadros endereçados a um endereço de multicast, se ele tiver sido instruído a escutar esse 
endereço 

e Todos os quadros, se estiver no modo promíscuo 


Ele passa ao host somente os quadros que são aceitos. 


Algoritmo do transmissor 
Como vimos, o lado receptor do protocolo Ethernet é simples; a inteligência real é implementada no 
lado do emissor. O algoritmo do transmissor é definido da seguinte forma. 

Quando o adaptador tem um quadro para enviar e a linha está ociosa, ele transmite o quadro 
imediatamente; não existe negociação com os outros adaptadores. O limite superior de 1.500 bytes na 
mensagem significa que o adaptador pode ocupar a linha somente por um período de tempo fixo. 

Quando um adaptador tem um quadro para enviar e a linha está ocupada, ele esperar até que a linha 
esteja ociosa e depois transmite imediatamente.º O Ethernet é considerado um protocolo 1-persistente, 
pois um adaptador com um quadro para enviar transmite com probabilidade 1 sempre que uma linha 
ocupada fica ociosa. Em geral, um algoritmo p-persistente transmite com probabilidade 0 < p < 1 depois 
que a linha se torna ociosa e adia a transmissão com probabilidade q=1 — p. O raciocínio por trás da 


Para ser mais exato, todos os adaptadores esperam 9,6 us após o final de um quadro antes de começar a transmitir o 
próximo quadro. Isso acontece tanto para o emissor do primeiro quadro como para aqueles nós escutando a linha para saber 
se ela está ociosa. 





Capítulo 2 e Conectando-se 77 
EASi 
ELSEVIER 


escolha de um p < 1 é que pode haver vários adaptadores esperando até que a linha ocupada se torne 
ociosa, e não queremos que todos eles comecem a transmitir ao mesmo tempo. Se cada adaptador 
transmite imediatamente com uma probabilidade de, digamos, 33%, então até três adaptadores podem 
estar esperando para transmitir e provavelmente apenas um começará a transmitir quando a linha se 
tornar ociosa. Apesar desse raciocínio, um adaptador Ethernet sempre transmite imediatamente após 
notar que a rede se tornou ociosa, e faz isso com bastante eficiência. 

Para concluir a história sobre os protocolos p-persistentes para o caso em que p < 1, você poderia se 
perguntar por quanto tempo um emissor que perde no cara ou coroa (ou seja, decide adiar a transmissão) 
precisa esperar antes que possa transmitir. A resposta para a rede Aloha, que desenvolveu originalmente 
esse estilo de protocolo, era dividir o tempo em parcelas discretas de tempo, ou slots, com cada slot 
correspondendo ao período de tempo necessário para transmitir um quadro inteiro. Sempre que um 
nó tem um quadro para enviar e ele percebe um slot vazio (ocioso), ele transmite com probabilidade p 
e adia a transmissão para o próximo slot com probabilidade q= 1 — p. Se esse slot também estiver vazio, 
o nó novamente decide transmitir ou adiar a transmissão, com probabilidades p e q, respectivamente. 
Se esse próximo slot não estiver vazio — ou seja, alguma outra estação decidiu transmitir -, então o nó 
simplesmente espera pelo próximo slot ocioso e o algoritmo é repetido. 

Voltando à nossa discussão sobre o Ethernet, como não existe um controle centralizado, é possível 
que dois (ou mais) adaptadores comecem a transmitir ao mesmo tempo, ou porque ambos encontraram 
a linha ociosa ou porque ambos ficaram esperando até que uma linha ocupada ficasse ociosa. Quando 
isso acontece, dizemos que os dois (ou mais) quadros colidem na rede. Cada emissor, como o Ethernet 
admite detecção de colisão, é capaz de determinar que houve uma colisão. No momento em que um 
adaptador detecta que seu quadro está colidindo com outro, ele primeiro transmite uma sequência de 
jamming (interferência proposital) de 32 bits e depois interrompe a transmissão. Assim, o transmitir 
no mínimo enviará 96 bits no caso de uma colisão: 64 bits de preâmbulo mais 32 bits da sequência de 
jamming. 

Uma forma de um adaptador enviar apenas 96 bits — que às vezes é chamado de quadro anão — é se 
dois hosts estiverem próximos um do outro. Se os dois hosts estivessem distantes, eles teriam que trans- 
mitir por mais tempo, e portanto enviar mais bits, antes de detectar a colisão. De fato, o pior cenário 
possível acontece quando os dois hosts estão em extremidades opostas da rede Ethernet. Para saber ao 
certo que o quadro que ele enviou não colidiu com outro quadro, o transmissor pode ter que enviar até 
512 bites (64 bytes): 14 bytes de cabeçalho mais 46 bytes de dados mais 4 bytes de CRC. 

Por que 512 bits? A resposta está relacionada a outra pergunta que você poderia fazer sobre uma rede 
Ethernet: por que seu tamanho está limitado a apenas 2.500 m? Por que não 10 ou 1.000 km? A resposta 
para as duas perguntas tem a ver com o fato de que, quanto mais afastados estiverem dois nós, mais 
tempo é necessário para que um quadro enviado por um nó alcance o outro, e a rede fica vulnerável a 
uma colisão durante esse tempo. 

A Figura 2.26 ilustra o pior cenário, onde os hosts A e B estão em extremidades opostas da rede. 
Suponha que o host A comece a transmitir um quadro no instante t, como mostra a parte (a) da figura. 
Leva apenas uma latência do enlace (vamos indicar a latência como d) para que o quadro alcance o 
host B. Assim, o primeiro bit do quadro de A chega em A no instante t+ d, como mostra a parte (b). 
Suponha que um instante antes que o quadro do host A chegue (ou seja, B ainda vê uma linha ociosa), 
o host B comece a transmitir seu próprio quadro. O quadro de B colidirá imediatamente com o quadro 
de A, e essa colisão será detectada pelo host B (c). O host B enviará uma sequência de jamming de 32 
bits, conforme descrevemos anteriormente. (O quadro de B não será um quadro anão.) Infelizmente, o 
host A não saberá que a colisão aconteceu até que o quadro de B o alcance, o que acontecerá após uma 
latência do enlace, no instante t+2 x d, como mostra a parte (d). O host A precisa continuar a trans- 
mitir até esse momento, a fim de detectar a colisão. Em outras palavras, o host A precisa transmitir por 
2x d para ter certeza de ter detectado todas as colisões possíveis. Considerando que uma rede Ethernet 
em sua configuração máxima tem 2.500 m de comprimento, e que pode haver até quatro repetidores 
entre dois hosts quaisquer, o atraso de ida e volta pode chegar a até 51,2 us, que em uma Ethernet de 10 
Mbps corresponde a 512 bits. A outra maneira de analisarmos essa situação é que precisamos limitar 
a latência máxima da rede Ethernet para um valor razoavelmente pequeno (por exemplo, 51,2 us) para 
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(a) A B FIGURA 2.26 Pior cenário: (a) A envia um quadro no instante t; (b) O quadro 
pu pao de A chega em B no instante t+ d; (c) B começa a transmitir no instante t+d 
e colide com o quadro de A; (d) O quadro anão de B (32 bits) chega em A no 
lá instante t+2d. 
| | 
(b) A B 
E iin a 1 
(c) A B 
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que o algoritmo de acesso funcione; portanto, o tamanho máximo de uma rede Ethernet precisa ser 
algo na ordem de 2.500 m. 

Quando um adaptador tiver detectado uma colisão e encerrado sua transmissão, ele espera por 
um período de tempo e tenta novamente. Toda vez que ele tenta transmitir e falha, o adaptador dobra 
o tempo que ele espera antes de tentar novamente. Essa estratégia de dobrar o intervalo de espera 
entre cada tentativa de retransmissão é uma técnica geral conhecida como recuo exponencial. Mais 
precisamente, o adaptador primeiro espera 0 ou 51,2 us, escolha que é feita aleatoriamente. Se esse 
esforço falhar, então ele espera 0, 51,2, 102,4 ou 153,6 us (escolha feita aleatoriamente) antes de tentar 
novamente; isso significa k x 51,2 para k=0 ... 3. Após a terceira colisão, ele espera k x 51,2, para k=0 
... 23 — 1, novamente escolhido aleatoriamente. Em geral, o algoritmo seleciona aleatoriamente um k 
entre 0 e 2” — le espera k x 51,2 us, onde n é o número de colisões experimentadas até o momento. O 
adaptador desiste depois de certo número de tentativas e informa um erro de transmissão ao host. Os 
adaptadores normalmente tentam novamente até 16 vezes, embora o algoritmo de recuo limite n ao 
valor 10 na fórmula apresentada. 


2.6.3 Experiência com Ethernet 


Como as redes Ethernet já existem há tantos anos e são tão populares, temos muita experiência com 
seu uso. Uma das observações mais importantes que as pessoas têm feito sobre as redes Ethernet de 
acesso múltiplo é que elas funcionam melhor sob condições de pouca carga de tráfego. Isso porque, 
sob altas cargas (normalmente, uma utilização de mais de 30% é considerada alta em uma Ethernet), 
grande parte da capacidade da rede é desperdiçada com colisões. 

Para aliviar esses problemas, as redes Ethernet de acesso múltiplo normalmente eram usadas de uma 
maneira muito mais conservadora do que o padrão permite. Por exemplo, a maioria das redes Ethernet 
tinha menos de 200 hosts conectados a elas, o que é muito menos do que o máximo de 1.024. De modo 
semelhante, a maioria dessas redes tinha muito menos do que 2.500 m, com um atraso de ida e volta 
mais próximo de 5 ps do que de 51,2 us. Outro fator que tornou as redes Ethernet práticas é que, embora 
os adaptadores Ethernet não implementem controle de fluxo no nível de enlace, os hosts normalmente 
oferecem um mecanismo de controle de fluxo fim a fim, conforme veremos mais adiante. Como resultado, 
é raro encontrar situações em que qualquer host esteja continuamente bombeando quadros para rede. 
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Finalmente, temos que dizer algo a respeito do motivo pelo qual as redes Ethernet têm tido tanto sucesso, 
para podermos entender as propriedades que devemos emular com qualquer tecnologia de LAN que tente 
substituí-la. Primeiro, uma rede Ethernet é extremamente fácil de administrar e manter: não existem swit- 
ches nas redes Ethernet originais, nem tabelas de roteamento ou de configuração que precisam ser mantidas 
atualizadas, e é fácil adicionar um novo host à rede. É difícil imaginar uma rede mais simples de adminis- 
trar. Em segundo lugar, ela é barata. O cabo é barato e o único outro custo é o adaptador de rede em cada 
host. O padrão Fthernet tornou-se fortemente estabelecido por esses motivos, e qualquer técnica baseada 
em switch que aspirasse substituí-lo exigia investimento adicional na infraestrutura (os switches), além do 
custo de cada adaptador. Como veremos no próximo capítulo, uma tecnologia baseada em switches acabou 
tendo sucesso ao substituir as redes Ethernet de acesso múltiplo: a rede Ethernet comutada. A manutenção 
da simplicidade de administração (e a familiaridade) foi um motivo chave para esse sucesso. 


2.7 Redes sem fios & 


WLAN 

As tecnologias sem fios diferem dos enlaces com fios de algumas maneiras importantes, embora ao 
mesmo tempo compartilhem muitas propriedades comuns. Assim como os enlaces com fios, problemas 
de erros de bits são uma grande preocupação - normalmente, ainda mais devido ao ambiente de ruído 
imprevisível da maioria dos enlaces sem fios. O enquadramento e a confiabilidade também precisam 
ser tratados. Diferentemente dos enlaces com fios, a potência é uma grande preocupação nas redes sem 
fios, especialmente porque os enlaces sem fios normalmente são usados por pequenos dispositivos 
móveis (como telefones e sensores) que possuem acesso limitado a energia (por exemplo, uma pequena 
bateria). Além disso, você não pode sair aumentando arbitrariamente a potência de um transmissor de 
rádio — existem questões de interferência com outros dispositivos e, normalmente, regulamentações 
sobre a potência máxima que um dispositivo qualquer pode emitir em determinada frequência. 

Os meios sem fios também são inerentemente de acesso múltiplo; é difícil direcionar sua transmissão 
de rádio para um único receptor ou evitar o recebimento de sinais de rádio de qualquer transmissor com 
potência suficiente na sua vizinhança. Logo, o controle de acesso ao meio é uma questão fundamental 
para os enlaces sem fios. E, como é difícil controlar quem recebe seu sinal quando você o transmite 
pelo ar, questões de escuta indevida também podem ter que ser resolvidas. 


ONDE ESTÃO ELES AGORA? JA “seca: 


TOKEN RINGS 

Durante muitos anos, havia duas maneiras principais de montar uma LAN: Ethernet ou token ring (anel de 
fichas). A forma mais predominante de token ring foi inventada pela IBM e padronizada como IEEE 802.5. Token 
rings possuem várias características em comum com a Ethernet: o anel se comporta como um único meio 
compartilhado e emprega um algoritmo distribuído para decidir qual estação pode transmitir nesse meio em 
certo momento, e todos os nós em determinado anel podem ver todos os pacotes transmitidos por outros nós. 

A diferença mais óbvia entre token ring e Ethernet é a topologia; enquanto uma rede Ethernet é um 
barramento, os nós em uma rede token ring formam um ciclo. Ou seja, cada nó está conectado a um par de 
vizinhos, um acima e outro abaixo. O “token” é simplesmente uma sequência especial de bits que circula o 
anel; cada nó recebe e depois encaminha o token. Quando um nó que tenha um quadro a transmitir encontra 
o token, ele retira o token do anel (ou seja, ele não encaminha o padrão de bits especial) e insere seu quadro 
no anel. Cada nó ao longo do caminho simplesmente encaminha o quadro, com o nó de destino salvando 
uma cópia e encaminhando a mensagem para o próximo nó no anel. Quando o quadro chega de volta ao 
emissor, esse nó retira seu quadro do anel (em vez de continuar a encaminhá-lo) e reinsere o token. Desse 
modo, algum outro nó mais adiante no anel terá a oportunidade de transmitir um quadro. O algoritmo de 
acesso ao meio é justo no sentido em que, à medida que o token circula pelo anel, cada nó tem oportunidade 
de transmitir. Os nós são atendidos em uma froma de rodízio. 

Muitas variantes diferentes dos token rings apareceram nas últimas décadas; a Fiber Distributed Data 
Interface (FDDI) uma das últimas a apresentar uma adoção significativa. No final, as redes token ring 
perderam para as redes Ethernet, especialmente com o surgimento das redes Ethernet comutadas e variantes 
Ethernet de alta velocidade (Ethernet 100 Mb e gigabit). 
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Tabela 2.4 Visão geral das principais tecnologias de rede sem fios 





Bluetooth (802.15.1) Wi-Fi (802.11) Celular 3G 
Comprimento típico do enlace 10m 100 m Dezenas de quilômetros 
Taxa de transferência de dados típica 2 Mbps (compartilhado) 54 Mbps (compartilhado) Centenas de kbps (por conexão) 
Uso típico Conexão de um periférico a Conexão de um computador Conexão de um telefone móvel 
um computador a uma base com fio a uma torre com fio 
Analogia da tecnologia com fios USB Ethernet DSL 


Há uma variedade desconcertante de diferentes tecnologias sem fios, cada uma tentando equilibrar 
diferentes requisitos em várias dimensões. Um modo simples de categorizar as diferentes tecnologias é 
pelas taxas de transferência de dados que elas oferecem e pela distância que os nós comunicantes podem 
estar um do outro. Outras diferenças importantes incluem qual parte do espectro eletromagnético elas 
utilizam (inclusive se isso exige uma licença) e quanta potência elas consomem. Nesta seção, vamos 
discutir três tecnologias de redes sem fios predominantes: Wi-Fi (também conhecida como 802.11), 
Bluetoothº e a família de terceira geração, ou “3G”, de padrões sem fios para celular. A Tabela 2.4 apre- 
senta uma visão geral dessas tecnologias e como elas se comparam umas com as outras. 

Você deve se lembrar, da Seção 1.5, que a largura de banda às vezes significa a largura de uma 
banda de frequência em hertz e às vezes a taxa de transferência de dados de um enlace. Como esses 
dois conceitos aparecem em discussões de redes sem fios, vamos usar largura de banda aqui em seu 
sentido mais estrito — largura de uma banda de frequência — e usar o termo taxa de transferência de 
dados para descrever o número de bits por segundo que podem ser enviados pelo enlace, como na 
Tabela 2.4. 

Como todos os enlaces sem fios compartilham o mesmo meio, o desafio é compartilhar esse meio 
com eficiência, sem interferir excessivamente uns com os outros. A maior parte desse compartilhamento 
é feita dividindo-o nas dimensões da frequência e do espaço. O uso exclusivo de determinada frequência 
em uma área geográfica em particular pode ser alocado a uma entidade individual, como uma empresa. 
É viável limitar a área coberta por um sinal eletromagnético, pois esses sinais se enfraquecem, ou se 
atenuam, com a distância a partir de sua origem. Para reduzir a área coberta pelo seu sinal, reduza a 
potência do seu transmissor. 

Essas alocações normalmente são determinadas por agências do governo, como a Federal Communi- 
cations Commission (FCC) nos Estados Unidos.” Bandas específicas (faixas de frequência) são alocadas 
para certos usos. Algumas bandas são reservadas para uso pelo governo. Outras bandas são reserva- 
das para usos como rádio AM, rádio FM, televisão, comunicação por satélite e telefones celulares. 
Frequências específicas dentro dessas bandas são então licenciadas a organizações individuais para 
uso dentro de certas áreas geográficas. Finalmente, várias bandas de frequência são reservadas para uso 
sem licença — bandas em que uma licença não é necessária. 

Os dispositivos que utilizam frequências sem licença ainda estão sujeitos a certas restrições para que 
esse compartilhamento, de outra forma irrestrito, funcione. A mais importante delas é um limite sobre 
a potência de transmissão. Isso limita o alcance de um sinal, tornando menos provável que ele interfira 
com outro sinal. Por exemplo, um telefone sem fio (um dispositivo não licensiado comum) poderia ter 
um alcance de aproximadamente 30 metros. 

Uma ideia que aparece muito quando o espectro é compartilhado entre muitos dispositivos e 
aplicações é o espalhamento espectral. A ideia por trás do espalhamento espectral é espalhar o sinal 
por uma banda mais larga de frequências, de modo a minimizar o impacto da interferência de outros 
dispositivos. (O espalhamento espectral foi projetado originalmente para uso militar, de modo que esses 
“outros dispositivos” normalmente estavam tentando impedir a transmissão do sinal.) Por exemplo, o 
salto de frequência é uma técnica de espalhamento espectral que envolve a transmissão do sinal por uma 
sequência aleatória de frequências; ou seja, primeiro transmitir em uma frequência, depois em uma 
segunda, depois em uma terceira e assim por diante. A sequência de frequências não é verdadeiramente 
aleatória, mas é calculada algoritmicamente por um gerador de números pseudoaleatórios. O receptor 


No Brasil, a agência responsável por esta alocação é a Agência Nacional de Telecomunicações (Anatel). (N.T.) 
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0 E O Fluxo de dados: 1010 


0 | | | | Sequência aleatória: 0100101101011001 











ol | | | | | | XOR dos dois: 1011101110101001 
FIGURA 2.27 Exemplo da sequência de fichas de 4 bits. 


usa o mesmo algoritmo do emissor e o inicializa com a mesma semente; logo, ele é capaz de saltar para 
frequências em sincronismo com o transmissor, para receber o quadro corretamente. Esse esquema 
reduz a interferência, tornando bastante improvável que dois sinais estejam usando a mesma frequência 
por mais do que um infrequente bit isolado. 

Uma segunda técnica de espalhamento espectral, chamada sequência direta, acrescenta redundância 
para aumentar a tolerância a interferências. Cada bit de dados é representado por vários bits no sinal 
transmitido de modo que, se alguns dos bits transmitidos forem danificados pela interferência, normal- 
mente haverá redundância suficiente para recuperar o bit original. Para cada bit que o emissor deseja 
transmitir, ele na realidade envia o OU exclusivo desse bit com n bits aleatórios. Assim como no salto 
de frequência, a sequência de bits aleatórios é gerada por um gerador de números pseudoaleatórios, 
conhecido pelo emissor e pelo receptor. Os valores transmitidos, conhecidos como código de fichas de n 
bits, espalha o sinal por uma banda de frequência que é n vezes mais larga do que o quadro teria exigido 
de outra forma. A Figura 2.27 mostra um exemplo de uma sequência de fichas de 4 bits. 

Diferentes partes do espectro eletromagnético possuem diferentes propriedades, tornando algumas 
mais adequadas à comunicação e outras menos adequadas. Por exemplo, algumas podem penetrar em 
prédios e outras não. Os governos controlam apenas a parte principal da comunicação: as faixas de rádio 
e micro-ondas. À medida que a demanda pelo espectro principal aumenta, há um grande interesse no 
espectro que está se tornando disponível à medida que a televisão analógica é substituída pela digital.!º 

Em muitas redes sem fios atuais, observamos que existem duas classes diferentes de terminais. Um 
deles, às vezes denominado como estação base, normalmente não tem mobilidade, mas tem uma conexão 
com fios (ou, pelo menos, com elevada largura de banda) com a Internet ou outras redes, como mostra a 
Figura 2.28. O nó na outra extremidade do enlace —- mostrado aqui como nó cliente - normalmente é móvel 
e depende de seu enlace com a estação base para realizar toda a sua comunicação com outros nós. 

Observe que, na Figura 2.28, usamos um par de ondas com linhas que representam uma abstração 
de “ligação” sem fios fornecida entre dois dispositivos (por exemplo, entre uma estação base e um de 
seus nós cliente). Um dos aspectos interessantes da comunicação sem fios é que ela naturalmente 
admite a comunicação ponto a multiponto, pois as ondas de rádio enviadas por um dispositivo podem 
ser recebidas simultaneamente por muitos dispositivos. Porém, normalmente é útil criar uma abstração 
de enlace ponto a ponto para protocolos de camada superior, e veremos, em outra parte desta seção, 
alguns exemplos de como isso funciona. 

Observe que, na Figura 2.28, a comunicação entre os nós não base (clientes) é roteada por meio 
da estação base. Isso acontece apesar do fato de que as ondas de rádio emitidas por um nó cliente 
podem ser recebidas por outros nós cliente —- o modelo de estação base compartilhada não permite a 
comunicação direta entre os nós cliente. 

Essa topologia implica em três níveis de mobilidade qualitativamente diferentes. O primeiro nível 
é nenhuma mobilidade, como quando um receptor precisa estar em um local fixo para receber uma 
transmissão direcional da estação base. O segundo nível é a mobilidade dentro do alcance de uma base, 
como acontece com o Bluetooth. O terceiro nível é a mobilidade entre as bases, como acontece com 
telefones celulares e Wi-Fi. 


10Graças aos avanços na codificação e modulação de vídeo, as transmissões de vídeo digital exigem menos espectro alocado 
para cada canal de TV. 
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FIGURA 2.28 Uma rede sem fios usando uma estação base. 


Uma topologia alternativa que está ganhando interesse crescente é a rede em malha ou ad hoc. Em 
uma malha sem fios, os nós são pares independentes; ou seja, não existe um nó especial que atua como 
estação base. As mensagens podem ser encaminhas por uma cadeia de nós, contanto que cada nó esteja 
dentro do alcance do nó anterior. Isso é ilustrado na Figura 2.29. Isso permite que a parte sem fios de 
uma rede se estenda além do alcance limitado de um único rádio. Do ponto de vista da competição 
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FIGURA 2.29 Uma rede sem fios ad hoc ou em malha. 
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entre as tecnologias, isso permite que uma tecnologia de alcance mais curto estenda seu alcance e 
potencialmente concorra com uma tecnologia de alcance maior. As malhas também oferecem tolerância 
a falhas, fornecendo várias rotas para uma mensagem seguir do ponto A ao ponto B. Uma rede em ma- 
lha pode ser estendida de forma incremental, com custos incrementais. Entretanto, a rede em malha 
exige que os nós não base tenham um nível de sofisticação em seu hardware e software, potencialmente 
aumentando os custos por unidade e o consumo de potência, uma consideração crítica para dispositivos 
alimentados por bateria. As redes em malha sem fios possuem um interesse de pesquisa considerável 
(veja a seção de leitura adicional para obter algumas referências), mas elas ainda estão relativamente 
em sua infância em comparação com as redes com estação base. As redes de sensores sem fios, outro 
tipo de tecnologia emergente em alta, normalmente forma malhas sem fios. 

Agora que explicamos algumas das questões comuns das redes sem fios, vejamos os detalhes de 
algumas tecnologias sem fios comuns. 


2.7.1 802.11Wi-Fi 


Amaioria dos leitores já devem ter usado uma rede sem fios baseada nos padrões IEEE 802.11, normal- 
mente conhecido como Wi-Fi.!! Wi-Fi é tecnicamente uma marca registrada, pertencente a um grupo 
comercial chamado Wi-Fi Alliance, que certifica a compatibilidade de produtos com o padrão 802.11. 
Assim como o Ethernet, o 802.11 foi projetado para uso em uma área geográfica limitada (casas, prédios 
de escritórios, universidades) e seu desafio principal é mediar o acesso a um meio de comunicação 
compartilhado — neste caso, sinais propagando-se pelo espaço. 


Propriedades físicas 

O 802.11 define uma série de camadas físicas diferentes, que operam em diversas bandas de frequência 
e oferecem uma série de velocidades de dados diferentes. No momento em que este livro foi escrito, o 
802.11n oferece a velocidade de dados mais alta, chegando a 600 Mbps. 

O padrão 802.11 original definia dois padrões de camadas físicas baseados em rádio, um usando salto 
de frequência (sobre 79 larguras de banda de frequência de 1 MHz de largura cada) e outro usando o 
espalhamento espectral com sequência direta (com uma sequência de fichas de 11 bits). Ambos forne- 
ciam velocidades de dados na faixa de 2 Mbps. O padrão da camada física 802.11b foi acrescentado mais 
tarde. Usando uma variante da sequência direta, o 802.11b oferece até 11 Mbps. Todos esses três padrões 
operavam na faixa de frequência de 2,4 GHz do espectro eletromagnético, sem necessidade de licença. 
Depois veio o 802.11a, que oferece até 54 Mbps usando uma variante da FDM, chamada multiplexação 
ortogonal por divisão de frequência (OFDM - Orthogonal Frequency Division Multiplexing); o 802.1l1a 
opera na faixa de 5 GHz sem necessidade de licença. Por um lado, essa banda é menos utilizada, de 
modo que há menos interferência. Por outro lado, existe mais absorção do sinal e ele é limitado quase 
que à linha de visada. O 802.11g veio em seguida; o 802.11g também usa OFDM, oferece até 54 Mbps e 
é compatível com 802.11b (e retorna à banda de 2,4 GHz). 

Mais recentemente, o 802.11n apareceu em cena, com um padrão que foi aprovado em 2009 (embora 
também existissem produtos anteriores ao padrão). O 802.11n apresenta avanços consideráveis na 
taxa de transferência dados máxima possível, usando várias antenas e permitindo maiores larguras de 
banda do canal sem fios. O uso de várias antenas normalmente é chamado de MIMO (Multiple-Input, 
Multiple-Output — entrada múltipla, saída múltipla). 

É comum que produtos comerciais ofereçam suporte a mais de um tipo de 802.11; algumas 
estações base dão suporte a todas as quatro variantes (a, b, g, n). Isso não apenas garante a compa- 
tibilidade com qualquer dispositivo que ofereça suporte a qualquer um dos padrões, mas também 
permite que dois desses produtos escolham a opção de largura de banda mais alta para determinado 
ambiente. 


HExiste algum debate sobre a questão de se Wi-Fi significa “wireless fidelity” (fidelidade sem fio), por analogia a Hi-Fi (high 
fidelity ou alta fidelidade), ou se é apenas um nome sugestivo que não significa nada além de 802.11. 
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Vale a pena observar que, embora todos os padrões 802.11 definam uma taxa de transferência bits 
máxima que pode ser aceita, a maior parte deles também oferece suporte a taxas de transferência de 
bits mais baixas; por exemplo, o 802.11a permite taxas de transferência de bits de 6, 9, 12, 18, 24, 36, 48 
e 54 Mbps. Em taxas de transferência de bits menores, é mais fácil decodificar os sinais transmitidos 
na presença de ruído. Diferentes esquemas de modulação são usados para alcançar as diversas taxas 
de transferência de bits; além disso, a quantidade de informações redundantes na forma de códigos 
corretores de erros é variada. (Veja, na Seção 2.4, uma introdução aos códigos de detecção de erros.) 
Uma maior quantidade de informação redundante significa maior resiliência a erros de bits ao custo 
de reduzir a taxa de transferência de dados efetiva (pois uma maior parte dos bits transmitidos são 
redundantes). 

Os sistemas tentam obter uma taxa de transferência de bits ideal com base no ruído do ambiente 
em que se encontram; os algoritmos para a seleção de taxa de transferência de bits podem ser 
muito complexos (veja um exemplo na seção de Leitura Adicional). É interessante que os padrões 
802.11 não especificam uma técnica em particular, mas deixam a escolha dos algoritmos para os 
diversos fabricantes. A técnica básica para escolher uma taxa de transferência de bits é estimar a 
taxa de erros de bits, seja medindo diretamente a relação sinal-ruído (SNR) na camada física ou 
estimando a SNR medindo a frequência com que os pacotes são sucessivamente transmitidos e 
confirmados. Em algumas técnicas, um emissor ocasionalmente testará a possibilidade de usar 
uma taxa de transferência de bits mais alta enviando um ou mais pacotes nessa taxa para ver se 
ele tem sucesso. 


Prevenção de colisão 
À primeira vista, pode parecer que um protocolo sem fios siga o mesmo algoritmo do Ethernet - espere 
até que o enlace se torne ocioso antes de transmitir e recue caso ocorra uma colisão — e, em uma 
primeira aproximação, é isso que o 802.11 faz. A complicação adicional para as redes sem fios é que, 
enquanto um nó em uma rede Ethernet recebe as transmissões de cada um dos outros nós e pode 
transmitir e receber ao mesmo tempo, nenhuma dessas condições se aplica aos nós sem fios. Isso 
torna a detecção de colisões bem mais complexa. O motivo pelo qual os nós sem fios normalmente 
não podem transmitir e receber ao mesmo tempo (na mesma frequência) é que a potência gerada pelo 
transmissor é muito maior do que qualquer sinal recebido provavelmente terá e, portanto, domina 
completamente o circuito de recepção. O motivo pelo qual um nó pode não receber transmissões 
de outro nó é que esse nó pode estar muito distante ou estar bloqueado por algum obstáculo. Essa 
situação é um pouco mais complexa do que pode parecer inicialmente, conforme ilustraremos na 
discussão a seguir. 

Considere a situação representada na Figura 2.30, em que os nós A e C estão dentro do alcance do nó 
B, mas não um do outro. Suponha que A e C queiram se comunicar com B e, portanto, cada um envie 
um quadro. A e C não sabem da existência um do outro, pois seus sinais não têm alcance suficiente. 
Esses dois quadros colidem um com o outro em B, mas, diferente de uma rede Ethernet, nem A nem C 
percebem a colisão. A e C são considerados nós ocultos um em relação ao outro. 


FIGURA 2.30 O problema do nó oculto. Embora A e C 
estejam ocultos um do outro, seus sinais podem colidir em 
B. (O alcance de B não é mostrado.) 
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FIGURA 2.31 O problema do nó exposto. Embora B e C estejam 
expostos aos sinais um do outro, não existe interferência se 

B transmitir para A enquanto C transmite para D. (Os alcances 
de A e D não são mostrados.) 


Um problema relacionado, chamado de problema do nó exposto, ocorre sob as circunstâncias 
ilustradas na Figura 2.31, em que cada um dos quatro nós é capaz de enviar e receber sinais que 
alcançam apenas os nós em seus limites imediatos à esquerda e à direita. Por exemplo, B pode trocar 
quadros com A e C, mas não é capaz de alcançar D, enquanto C pode alcançar B e D, mas não A. 
Suponha que B esteja enviando algo para A. O nó C está ciente dessa comunicação, pois escuta a 
transmissão de B. Seria um erro, entretanto, se C concluísse que não pode transmitir para qualquer 
nó só porque ele pode escutar a transmissão de B. Por exemplo, suponha que C queira transmitir 
dados para o nó D. Isso não é um problema, pois a transmissão de C para D não interferirá com 
a capacidade de A receber dados de B. (Isso interferiria com A enviando para B, mas B está trans- 
mitindo em nosso exemplo.) 

O 802.11 trata desses problemas usando CSMA/CA, onde CA significa collision avoidance (prevenção 
de colisão), ao contrário de collision detection (detecção de colisão) do CSMA/CD, usado nas redes 
Ethernet. Existem alguns elementos necessários para que isso funcione. 

A parte de detecção de portadora (Carrier Sense) parece ser muito simples: antes de enviar um pacote, 
o transmissor verifica se é capaz de escutar quaisquer outras transmissões; se não puder, ele transmite. 
Porém, devido ao problema do terminal oculto, apenas esperar a ausência de sinais de outros trans- 
missores não garante que não haverá uma colisão do ponto de vista do receptor. Por esse motivo, uma 
parte do CSMA/CA é um ACK explícito do receptor para o emissor. Se o pacote foi decodificado com 
sucesso e seu CRC no receptor foi aceito, o receptor envia um ACK de volta ao emissor. 

Observe que, se houver uma colisão, o pacote inteiro será inútil.!2 Por esse motivo, o 802.11 acres- 
centa um mecanismo opcional chamado RTS-CTS (Ready to Send-Clear to Send). Isso de certa forma 
consegue resolver o problema do terminal oculto. O emissor envia um RTS - um pacote curto — para o 
receptor desejado e, se esse pacote for recebido com sucesso, o receptor responde com outro pacote 
curto, o CTS. Embora o RTS possa não ter sido ouvido por um terminal oculto, o CTS provavelmente 
será. Isso efetivamente diz aos nós dentro do alcance do receptor que eles não deverão enviar nada por 
algum tempo - o período de tempo da transmissão porvir é incluído nos pacotes RTS e CTS. Depois 
que for passado esse tempo mais um pequeno intervalo, a portadora pode ser considerada novamente 
disponível, e outro nó está livre para tentar enviar. 

Naturalmente, dois nós poderiam detectar um canal ocioso e tentar transmitir um quadro RTS ao 
mesmo tempo, fazendo com que seus quadros RTS colidam um com o outro. Os emissores percebem 
que a colisão aconteceu quando não recebem o quadro CTS após um período de tempo, quando cada 
um esperará por um período de tempo aleatório antes de tentar novamente. A quantidade de tempo 
que determinado nó espera é definida por um algoritmo de recuo exponencial muito semelhante ao 
usado em redes Ethernet (ver Seção 2.6.2). 

Após uma troca RTS-CTS bem-sucedida, o emissor envia seu pacote de dados e, se tudo correr bem, 
recebe um ACK para esse pacote. Caso um ACK não seja recebido dentro do intervalo adequado, o emissor 


!2Pesquisas atuais tentam recuperar pacotes parciais, mas isso ainda não faz parte do 802.11. 
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tentará solicitar novamente o uso do canal, usando o mesmo processo descrito anteriormente. Quando 
isto ocorrer, é claro, outros nós podem novamente tentar obter acesso ao canal simultaneamente. 


Sistema de distribuição 

Conforme descrevemos até aqui, o 802.11 seria adequado para uma rede com uma topologia em malha 
(ad hoc), e o desenvolvimento de um padrão 802.11s para redes em malha está quase terminado. No 
momento, porém, quase todas as redes 802.11 utilizam uma topologia orientada à estação base. 

Em vez de todos os nós serem criados iguais, alguns nós têm permissão para se locomover (por 
exemplo, seu notebook) e alguns estão conectados a uma infraestrutura de rede com fios. O 802.11 
chama essas estações base de pontos de acesso (APs — Access Points), e elas estão conectadas umas às 
outras por um chamado sistema de distribuição. A Figura 2.32 ilustra um sistema de distribuição que 
conecta três pontos de acesso, cada um atendendo aos nós em alguma região. Cada ponto de acesso 
opera sobre algum canal na faixa de frequência apropriada, e cada AP normalmente estará em um canal 
diferente dos seus vizinhos. 

Os detalhes do sistema de distribuição não são importantes para esta discussão — ele poderia ser uma 
rede Ethernet, por exemplo. O único ponto importante é que a rede de distribuição opera na camada 
de enlace, a mesma camada de protocolo dos enlaces sem fios. Em outras palavras, ela não depende de 
quaisquer protocolos de nível superior (como a camada de rede). 

Embora dois nós possam se comunicar diretamente entre si se eles estiverem dentro do alcance um 
do outro, a ideia por trás dessa configuração é que cada nó se associe a um ponto de acesso. Para que 
o nó A se comunique com o nó E, por exemplo, A primeiro envia um quadro ao seu ponto de acesso 
(AP-1), que encaminha o quadro pelo sistema de distribuição para AP-3, que finalmente transmite 
o quadro para E. Como AP-1 soube encaminhar a mensagem para AP-3 é algo que está além do escopo 
do 802.11; ele pode ter usado o protocolo de ponte descrito no próximo capítulo (Seção 3.1.4). O que o 
802.11 especifica é como os nós selecionam seus pontos de acesso e, algo mais interessante, como esse 
algoritmo funciona mesmo com os nós se movendo de uma célula para outra. 

A técnica para selecionar um AP é chamada de varredura, e envolve as quatro etapas a seguir: 


1. O nó envia um quadro Probe (sondagem). 

2. Todos os APs dentro do alcance respondem com um quadro Probe Response (resposta de 
sondagem). 

3. O nó seleciona um dos pontos de acesso e envia a esse AP um quadro Association Request (pedido 
de associação). 

4. O AP responde com um quadro Association Response (resposta de associação). 


Um nó emprega esse protocolo sempre que se associa à rede, bem como quando está insatisfeito com 
seu AP atual. Isso poderia acontecer, por exemplo, porque o sinal de seu AP atual enfraqueceu devido 
ao fato do nó ter se afastado dele. Sempre que um nó se associa a um novo AP o novo AP notifica o AP 
antigo sobre a mudança (isso acontece na etapa 4) por meio do sistema de distribuição. 


FIGURA 2.32 Pontos de acesso conectados a um 
sistema de distribuição. 





Sistema de distribuição 





Capítulo 2º Conectando-se 87 





i sh 
ELSEVIER 


FIGURA 2.33 Mobilidade dos nós. 





Sistema de distribuição 


Considere a situação da Figura 2.33, em que o nó C se move da célula atendida por AP-1 para a célula 
atendida por AP-2. Ao se mover, ele envia quadros Probe, que eventualmente resultam em quadros 
Probe Response de AP-2. Em algum ponto, C prefere AP-2 em vez de AP-1 e, portanto, associa-se a esse 
ponto de acesso. 

O mecanismo que descrevemos é chamado de varredura ativa, pois o nó está ativamente procurando 
um ponto de acesso. Os APs também enviam periodicamente um quadro de Beacon que anuncia as 
capacidades do ponto de acesso; estas informações incluem as taxas de transmissão suportadas pelo 
AP Isso é chamado de varredura passiva, e um nó pode mudar para esse AP com base no quadro de 
Beacon simplesmente enviando um quadro Association Request de volta ao ponto de acesso. 


Formato de quadro 

A maior parte do formato do quadro 802.11, que é representado na Figura 2.34, é exatamente o que 
poderíamos esperar. O quadro contém os endereços do nó de origem e destino, cada um com 48 bits 
de extensão; até 2.312 bytes de dados; e um CRC de 32 bits. O campo Controle contém três subcampos de 
interesse (não mostrados): um campo Tipo que indica se o quadro transporta dados, é um quadro RTS 
ou CTS ou está sendo usado pelo algoritmo de varredura, e um par de campos de 1 bit - chamados ToDS 
e FromDs - que são descritos a seguir. 

O que há de peculiar sobre o formato de quadro 802.11 é que ele contém quatro, ao invés de 
dois endereços. O modo como esses endereços são interpretados depende das configurações dos 
bits ToDS (“para o sistema de distribuição”) e FromDS (“proveniente do sistema de distribuição”) 
no campo Controle do quadro. Isso acontece para levar em consideração a possibilidade de que o 
quadro encaminhado tenha passado pelo sistema de distribuição, o que significaria que o emissor 
original não necessariamente é o mesmo que o nó transmissor mais recente. Um raciocínio seme- 
lhante se aplica ao endereço de destino. No caso mais simples, quando um nó está enviando dados 
diretamente para outro, os dois bits de DS são 0, End1 identifica o nó de destino e End2 identifica 
o nó de origem. No caso mais complexo, os dois bits de DS são fixados em 1, indicando que a 
mensagem foi de um nó sem fios para o sistema de distribuição, e depois do sistema de distribuição 
para outro nó sem fios. Com os dois bits marcados, End1 identifica o destino final, End2 identifica 
o emissor imediato (aquele que encaminhou o quadro do sistema de distribuição para o destino 
final), End3 identifica o destino intermediário (aquele que aceitou o quadro proveniente do nó sem 
fios e o encaminhou pelo sistema de distribuição) e End4 identifica a origem inicial. Em termos do 
exemplo dado na Figura 2.32, End1 corresponde a E, End2 identifica AP-3, End3 corresponde a AP-1 
e End4 identifica A. 


16 16 48 48 48 16 48 0-18,496 32 
Controle Duração Endi | End2 End3  SegCtrl End4 Payload CRC 


FIGURA 2.34 Formato de quadro 802.11. 
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2.7.2 Bluetooth® (802.15.1) 


O Bluetooth preenche o nicho das comunicações de muito curto alcance entre telefones móveis, PDAs, 
notebooks e outros dispositivos pessoais ou periféricos. Por exemplo, o Bluetooth pode ser usado para 
conectar um telefone móvel a um fone de ouvido ou um notebook a um teclado. Em termos gerais, o 
Bluetooth é uma alternativa mais conveniente para conectar dois dispositivos do que um fio. Nessas 
aplicações, não é necessário oferecer um alcance ou uma largura de banda muito grande. Isso significa 
que os rádios Bluetooth podem usar uma transmissão com potência muito baixa, pois a potência de trans- 
missão é um dos principais fatores que afetam a largura de banda e o alcance dos enlaces sem fio. Este é o 
tipo de aplicação alvo de dispositivos habilitados com Bluetooth — como a maioria deles é alimentada por 
bateria (como o onipresente fone de ouvido), é importante que eles não consumam muita potência.!* 

O Bluetooth opera na faixa não licenciada de 2,45 GHz. Enlaces Bluetooth possuem larguras de banda 
típicas em torno de 1 a 3 Mbps e um alcance de cerca de 10 m. Por esse motivo, e como os dispositivos 
de comunicação normalmente pertencem a um indivíduo ou grupo, o Bluetooth às vezes é categorizado 
como rede pessoal (PAN — Personal Area Network). 

O Bluetooth é especificado por um consórcio da indústrias chamado Bluetooth Special Interest Group. 
Ele especifica um conjunto inteiro de protocolos, indo além da camada de enlace e definindo protocolos 
de aplicação, que são chamados de perfis, para uma grande variedade de aplicações. Por exemplo, existe 
um perfil para sincronizar um PDA com um computador pessoal. Outro perfil fornece a um computador 
móvel acesso a uma LAN com fios como o 802.11, embora esse não fosse o objetivo original do Bluetooth. 
O padrão IEEE 802.15.1 é baseado no Bluetooth, mas exclui os protocolos de aplicação. 

A configuração de rede Bluetooth básica, chamada piconet, consiste em um dispositivo mestre e até 
sete dispositivos escravos, como mostra a Figura 2.35. Qualquer comunicação é feita entre o mestre e 
um escravo; os escravos não se comunicam diretamente uns com os outros. Como eles têm um papel 
mais simples, seu hardware e software Bluetooth podem ser mais simples e mais baratos. 

Como o Bluetooth opera em uma banda não licenciada, ele precisa usar uma técnica de espalhamento 
espectral (conforme discutimos no início desta seção) para lidar com possíveis interferências na banda. 


FIGURA 2.35 Uma piconet Bluetooth. 
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Ele usa salto de frequência com 79 canais (frequências), usando cada uma por 625 pus de cada vez. Isso 
oferece um slot de tempo natural para o Bluetooth usar para a multiplexação síncrona por divisão de 
tempo. Um quadro ocupa até 1, 3 ou 5 slots de tempo consecutivos. Apenas o mestre pode começar a 
transmitir em slots de número ímpar. Um escravo pode começar a transmitir em um slot de número 
par —- mas somente em resposta a uma solicitação do mestre durante o slot anterior, impedindo assim 
qualquer disputa entre os dispositivos escravos. 

Um dispositivo escravo pode estar estacionado; ou seja, ele é colocado em um estado inativo, de baixa 
potência. Um dispositivo estacionado não pode se comunicar na piconet; ele só pode ser reativado pelo 
mestre. Uma piconet pode ter até 255 dispositivos estacionados, além dos seus dispositivos escravos 
ativos. 

No âmbito da comunicação de muito baixa potência e curta duração, existem algumas outras 
tecnologias além do Bluetooth. Uma destas é o ZigBeeº, idealizado pela aliança ZigBee e padronizado 
como o padrão IEEE 802.15.4. Ele é projetado para situações onde os requisitos de largura de banda são 
baixos e o consumo de potência deve ser muito baixo, para fornecer vida longa à bateria. Ele também 
tem a finalidade de ser mais simples e mais barato do que Bluetooth, tornando financeiramente viável 
sua incorporação em dispositivos mais baratos, como sensores. Sensores estão se tornando uma classe 
cada vez mais importante de dispositivo de rede, à medida que a tecnologia avança para o ponto onde 
dispositivos pequenos muito baratos podem ser distribuídos em grandes quantidades para monitorar 
coisas como temperatura, umidade e consumo de energia em um prédio. 


2.7.3 Tecnologias de telefone celular 


Embora a tecnologia de telefone celular no início fosse voltada à comunicação por voz, os serviços de 
dados baseados em padrões de telefonia celular têm se tornado cada vez mais populares (graças, em 
parte, às capacidades computacionais cada vez maiores dos telefones móveis ou smartphones). Uma 
desvantagem em comparação com as tecnologias descritas até aqui é o custo para os usuários, em parte 
devido ao uso, pelas redes celulares, de um espectro licenciado (que historicamente tem sido vendido pa- 
ra as operadoras de telefonia celular por valores astronômicos). As bandas de frequência que são usadas 
para telefones celulares (e atualmente para dados via celular) variam no mundo inteiro. Na Europa, por 
exemplo, as principais bandas para telefones celulares estão em 900 MHz e 1.800 MHz. Na América do 
Norte, são usadas bandas de 850 MHz e 1.900 MHz.!* Essa variação global no uso do espectro cria pro- 
blemas para usuários que desejam viajar de uma parte do mundo para outra e criou um mercado para 
telefones que podem operar em várias frequências (por exemplo, um telefone tri-band pode operar em 
três das quatro bandas de frequência mencionadas). Esse problema, porém, é pequeno em comparação 
com a proliferação de padrões incompatíveis que assolaram o mercado de comunicações por celular. 
Somente há pouco tempo começaram a aparecer alguns sinais de convergência para um pequeno 
conjunto de padrões. Finalmente, existe o problema de que, como a maior parte da tecnologia celular 
foi projetada para comunicação de voz, a comunicação de dados com elevada largura de banda tem 
sido uma adição relativamente recente aos padrões. 

Assim como o 802.11 e o WiMAX, a tecnologia celular conta com o uso de estações base que fazem 
parte de uma rede com fios. A área geográfica atendida pela antena da estação base é chamada de célula. 
Uma estação base poderia atender a uma única célula ou usar várias antenas direcionais e atender a várias 
células. As células não possuem limites rígidos e se sobrepõem. Onde elas se sobrepõem, um telefone 
móvel poderia potencialmente se comunicar com várias estações base. Isso é de certa forma parecido 
com a imagem do 802.11 mostrada na Figura 2.32. A qualquer momento, porém, o telefone se comunica 
com, e fica sob o controle de, apenas uma estação base. Quando o telefone começa a sair de uma célula, 
ele se move para uma área de sobreposição com uma ou mais células. A estação base atual sente o sinal do 
telefone se enfraquecendo e passa o controle do telefone para qualquer estação base que esteja recebendo 
o sinal mais forte dele. Se o telefone estiver envolvido em uma chamada nesse momento, a chamada precisa 
ser transferida para a nova estação base, naquilo que é chamado de handoff (ou transferência). 


“No Brasil, é comum o uso das bandas 850, 1800 e 1900 (N.T.) 
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Como já observamos, não existe um padrão único para a comunicação celular, mas sim uma coleção 
de tecnologias concorrentes que dão suporte ao tráfego de dados de diferentes maneiras e oferecem 
diferentes velocidades. Essas tecnologias são classificadas de forma geral por geração. A primeira geração 
(1G) era analógica, e assim era de interesse limitado de um ponto de vista das comunicações de dados. 
Os padrões da segunda geração passaram a ser digitais e introduziram os serviços de dados sem fios, 
enquanto a terceira geração (3G) permitiu o uso de maior largura de banda e transmissão simultânea 
de voz e dados. A maioria das redes de telefonia móvel mais utilizadas atualmente dão suporte a algum 
tipo de 3G, com o suporte a 4G começando a aparecer. Como cada uma das gerações compreende uma 
família de padrões e tecnologias, normalmente é uma questão de debate (e interesse comercial) o fato 
de se uma rede em particular é 3G ou de alguma outra geração. 

O conceito de uma terceira geração foi estabelecido antes que houvesse qualquer implementação das 
tecnologias 3G, com o objetivo de modelar um único padrão internacional que oferecesse uma largura de 
banda muito maior do que tecnologias 2G. Infelizmente, não apareceu um único padrão, e essa tendência 
provavelmente continuará com o 4G. Porém, é interessante saber que a maioria dos padrões 3G é baseada 
em variantes do CDMA (Code Division Multiple Access ou Acesso Múltiplo por Divisão de Código). 

O CDMA usa uma forma de espalhamento espectral para multiplexar o tráfego de vários dispositivos 
para um canal sem fios em comum. Cada transmissor usa um código pseudoaleatório de fichas em uma 
frequência que é alta em relação à taxa de dados e envia o OU exclusivo dos dados com o código de fichas. 
O código de cada transmissor segue uma sequência que é conhecida pelo receptor alvo — por exemplo, 
uma estação base em uma rede celular atribui uma sequência de código exclusiva a cada dispositivo 
móvel ao qual está atualmente associado. Quando um grande número de dispositivos transmite seus 
sinais na mesma célula e banda de frequência, a soma de todas as transmissões se parece com um ruído 
aleatório. Porém, um receptor que conhece o código sendo usado por determinado transmissor pode 
extrair os dados desse transmissor do aparente ruído. 

Em comparação com outras técnicas de multiplexação, o CDMA tem algumas propriedades boas 
para dados de rajada. Não existe limite rígido sobre quantos usuários podem compartilhar uma faixa 
do espectro — você só precisa garantir que todos tenham códigos de fichas exclusivos. A taxa de erros de 
bits, porém, aumenta com o número cada vez maior de transmissores simultâneos. Isso o torna muito 
bem adequado para aplicações em que existem muitos usuários mas, a qualquer momento, muitos 
deles não estão transmitindo — o que descreve bem muitas aplicações de dados, como a navegação na 
Web. Além disso, em sistemas práticos, quando é difícil conseguir um forte sincronismo entre todos os 
aparelhos móveis, o CDMA consegue melhor eficiência espectral (ou seja, chega mais perto dos limites 
teóricos do teorema de Shannon-Hartley) do que outros esquemas de multiplexação, como o TDMA. 


PROBLEMAS DE CAMADA CRUZADA NAS REDES SEM FIOS 





Um aspecto interessante das redes sem fios, que tem recebido muita atenção da comunidade de pesquisa nos 
últimos anos, é o modo como elas desafiam as convenções das arquiteturas de protocolo em camadas. Por 
exemplo, os padrões 802.11 permitem que você crie uma abstração de um enlace que conecta um nó a outro 
de uma maneira semelhante ao ponto a ponto. Tendo feito isso, qualquer protocolo de camada superior pode 
simplesmente tratar o enlace como qualquer outro enlace ponto a ponto. Mas essa é a abordagem certa? 
Considere, por exemplo, três nós A, B e C em sequência, como mostrado na Figura 2.30. Se quisermos 
transmitir um pacote de A para C, uma técnica convencional seria que A enviasse um pacote para B e B 
enviasse o pacote para C. Porém, na realidade, o alcance de um determinado nó durante o envio de pacotes 
não é definido tão nitidamente quanto o círculo mostrado aqui, mas diminui lentamente com o aumento da 
distância. Assim, pode ser que A envie um pacote para C com, digamos, 30% de probabilidade de sucesso, 
enquanto pode enviar um pacote para B com 80% de probabilidade de sucesso. Assim, provavelmente (30% 
do tempo), não haveria necessidade de B encaminhar o pacote a C, pois C já o teria. Logo, pode ser bom que 
C diga a B “Não se importe em encaminhar esse pacote — eu já o tenho”. Essa técnica, na realidade, foi testada 
em uma plataforma de testes sem fios chamada Roofnet, perto do Massachusetts Institute of Technology, e 
demonstrou que a vazão aumenta substancialmente em comparação às técnicas convencionais. Mas essa 
técnica também significa que A, B e C não podem mais simplesmente atuar como se estivessem conectados 
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por enlaces simples; passamos informações que são relacionadas especificamente a enlaces sem fio para 
uma camada superior. Algumas pessoas bradariam “violação de camada” quando vissem tal coisa, enquanto 
outras (como os autores deste livro) admirariam a engenhosidade daqueles que melhoraram o desempenho, 
pensando além do uso tradicional das camadas. 

Existem inúmeros outros exemplos onde a passagem de alguma informação da camada de enlace sem 
fios para camadas mais altas pode oferecer benefícios; além disso, pode ser útil passar informações da 
camada física para a camada de enlace. Existe uma questão de equilíbrio delicada aqui. A disposição em 
camadas é uma ótima ferramenta — sem ela, as redes seriam extremamente difíceis de serem idealizadas e 
construídas em grande escala. Mas precisamos estar cientes de que, sempre que ocultamos informações — o 
que as camadas fazem - podemos perder algo que realmente teria sido melhor se não estivesse oculto. 
Devemos pensar no uso de camadas (ou qualquer outra forma de abstração) como uma ferramenta, em vez 
de uma regra inviolável. 





Segurança dos enlaces sem fios 

Um dos problemas bastante óbvios dos enlaces sem fios em comparação àqueles com fios ou às fibras 
óticas é que você não pode ter muita certeza de para onde seus dados foram. Você provavelmente é 
capaz de determinar se eles foram recebidos pelo receptor desejado, mas não há como saber quantos 
outros receptores poderiam ter capturado sua transmissão. Assim, se você estiver preocupado com a 
privacidade dos seus dados, as redes sem fios apresentam um desafio. 

Mesmo que você não esteja preocupado com a privacidade dos dados -ou talvez tenha cuidado disso de 
alguma outra maneira (veja uma discussão desse assunto no Capítulo 8) — poderá estar preocupado com um 
usuário não autorizado injetando dados em sua rede. No mínimo, esse usuário poderia ser capaz de consumir 
recursos que você preferiria consumir, como a largura de banda finita entre sua casa e seu provedor. 

Por esses motivos, as redes sem fios normalmente vêm com algum tipo de mecanismo para controlar 
o acesso ao próprio enlace e aos dados transmitidos. Esses mecanismos normalmente são categorizados 
como segurança sem fios. A segurança é um assunto vasto por si só, ao qual dedicamos o Capítulo 8, e 
veremos os detalhes da segurança sem fios nesse contexto na Seção 8.4.5. 


COMUNICAÇÕES VIA SATÉLITE 


Outra forma de comunicação sem fios que tem aplicação em certos cenários é baseada no uso de satélites. 
Os telefones via satélite (satphones) utilizam satélites de comunicação como estações base, comunicando-se 
em bandas de frequência que têm sido reservadas internacionalmente para uso por satélites. 
Consequentemente, o serviço está disponível até mesmo onde não existem estações base de serviço celular. 
Os telefones via satélite raramente são usados onde o celular está disponível, pois o serviço normalmente 


é muito mais caro. (Alguém precisa pagar para colocar os satélites em órbita.) Os satphones também são 
maiores e mais pesados do que os telefones celulares modernos, devido à necessidade de transmitir e 
receber por distâncias muito maiores para alcançar os satélites do que as torres de celular. A comunicação 
por satélite é mais utilizada na transmissão de televisão e rádio, tirando proveito do fato de que o sinal é 

de broadcast, e não ponto a ponto. A comunicação de dados com elevada largura de banda via satélite está 
disponível comercialmente, mas seu preço relativamente alto (para o equipamento e o serviço) limita seu uso 
a regiões onde não há outra alternativa disponível. 





2.8 Resumo 


Este capítulo introduziu os muitos e variados tipos de enlaces que são usados para conectar usuários a 
redes existentes e construir grandes redes a partir do zero. Embora os enlaces variem bastante em suas 
características detalhadas, existem muitos problemas e técnicas para solucioná-los que são comuns. 
Vimos os cinco principais problemas que precisam ser resolvidos para que dois ou mais nós conectados 
por algum meio possam trocar mensagens uns com os outros. 

O primeiro problema é codificar os bits que compõem uma mensagem binária em um sinal no nó de 
origem e depois recuperar os bits do sinal no nó receptor. Esse é o problema da codificação, e torna-se 
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desafiador pela necessidade de manter os relógios do emissor e do receptor sincronizados. Discutimos 
quatro técnicas de codificação diferentes — NRZ, NRZI, Manchester e 4B/5B -— que diferem bastante no 
modo como codificam as informações de relógio juntamente com os dados sendo transmitidos. Um 
dos principais atributos de um esquema de codificação é sua eficiência, a razão entre os pulsos de sinal 
e os bits codificados. 

Sendo possível transmitir bits entre os nós, o próximo passo é descobrir como empacotar esses bits 
em quadros. Esse é o problema do enquadramento, e se resume em poder reconhecer o início e o final 
de cada quadro. Novamente, examinamos várias técnicas diferentes, incluindo protocolos orientados 
a byte, protocolos orientados a bit e protocolos baseados em relógio. 

Supondo que cada nó seja capaz de reconhecer a coleção de bits que compõem um quadro, o terceiro 
problema é determinar se esses bits estão de fato corretos ou se possivelmente foram corrompidos em 
trânsito. Esse é o problema da detecção de erros, e examinamos três técnicas diferentes: verificação de 
redundância cíclica (CRC), paridade bidimensional e somas de verificação. Destas, a técnica de CRC 
oferece as garantias mais fortes e é a mais utilizada no nível de enlace. 

Visto que alguns quadros chegarão no nó de destino contendo erros e, portanto, terão que ser 
descartados, o próximo problema é como recuperar-se dessas perdas. O objetivo é fazer com que o 
enlace pareça confiável. A técnica geral para esse problema é chamada ARQ, e envolve o uso de uma 
combinação de confirmações e expirações de temporizadores. Vimos três algoritmos ARQ específicos: 
parar e esperar, janela deslizante e canais concorrentes. O que torna esses algoritmos interessantes é o 
modo como eles efetivamente usam o enlace, com o objetivo sendo manter o “tubo” cheio. 

O último problema não é relevante aos enlaces ponto a ponto, mas é a questão central em 
enlaces de acesso múltiplo: como mediar o acesso a um enlace compartilhado de modo que todos 
os nós em algum momento tenham uma chance de transmitir seus dados. Nesse caso, examinamos 
uma série de protocolos de acesso ao meio — Ethernet e vários protocolos sem fios — que têm sido 
usados na prática na criação de redes locais. O acesso ao meio nas redes sem fios torna-se mais 
complicado pelo fato de que alguns nós podem estar ocultos um do outro devido às limitações de 
alcance da transmissão de rádio. A maioria dos protocolos sem fios comuns hoje em dia designa 
alguns nós como nós com fios, ou estação base, enquanto os outros nós móveis se comunicam com 
uma estação base. Os padrões e as tecnologias das redes sem fios estão evoluindo rapidamente, 
com o surgimento das redes em malha, por exemplo, nas quais todos os nós se comunicam como 
pares independentes. 


E E O que vem em seguida: “a Internet das coisas” E 


À medida que o poder de processamento e a capacidade de memória de dispositivos pequenos e 
baratos, com baixa potência, continuam a aumentar, o próprio conceito de um “host” da Internet 
tem sofrido uma mudança significativa. Se por um lado a Internet das décadas de 1970 e 1980 era 
usada principalmente para conectar computadores fixos e os hosts da Internet de hoje são frequen- 
temente notebooks ou telefones móveis, está se tornando viável pensar em objetos muito menores, 
como sensores e atuadores, como hosts possíveis da Internet. Esses dispositivos são tão pequenos 
e potencialmente numerosos que levaram ao conceito de uma “Internet de coisas” — uma Internet 
com a qual a maioria dos objetos, variando desde interruptores de luz e caixas de estoque em uma 
fábrica, poderiam ser “hosts” endereçáveis na Internet. 

Embora o conceito de interligação de grandes quantidades de minúsculos objetos em rede possa 
parecer ficção científica (e talvez até ficção antiutópica), existem muitas aplicações concretas e práti- 
cas dessa ideia. Uma das mais populares é a ideia de controlar o consumo de energia adicionando-se 
capacidade de rede aos aparelhos eletrodomésticos. Interruptores de luz, tomadas elétricas e outros 
aparelhos poderiam possuir sensores (para medir o uso de eletricidade, a temperatura ambiente 
etc.) e atuadores (por exemplo, para controlar quando os dispositivos estão ativos, como ao adiar 
o uso de uma máquina de lavar até um horário fora de pico, quando a eletricidade é mais barata). 
Esse conceito aparece frequentemente sob o título de “redes elétricas inteligentes” e hoje está sendo 
examinado ativamente por companhias de eletricidade e vendedores de equipamentos. 
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Levar o uso de redes a trilhões dispositivos pequenos, de baixa potência, baratos e conectados 
intermitentemente ocasiona uma série de desafios técnicos. Como um exemplo simples, o projeto 
do IP versão 6, que discutiremos no Capítulo 4, foi influenciado de certa forma pela observação de 
que o número de endereços necessários pode ser muito maior do que o número de computadores 
convencionais no mundo. De modo semelhante, novos protocolos de roteamento estão sendo 
desenvolvidos para mover dados de forma eficiente entre dispositivos que podem ter reduzida 
disponibilidade de energia e conexões sem fios pouco confiáveis com o restante do mundo. Existem 
até mesmo novos sistemas operacionais desenvolvidos especificamente para serem executados em 
pequenos dispositivos com potência, CPU e recursos de memória limitados. 

O modo exato como essa visão da “Internet de coisas” se desenrolará ainda não sabemos, mas 
neste ponto parece claro que a Internet está se movendo para longe da visão original de apenas in- 
terconectar computadores. Aplicações que são habilitadas pela interconexão de trilhões de objetos 
inteligentes estão começando a ser observadas. 


Leitura adicional 


Uma das contribuições mais importantes nas redes de computadores durante os últimos 20 anos é o artigo original de 
Metcalf e Boggs (1976) introduzindo o conceito de Ethernet. Muitos anos depois, Boggs, Mogul e Kent (1988) relataram 
suas experiências práticas com a Ethernet, desmistificando muitos dos mitos que eles encontraram na literatura com 
o passar dos anos. Os dois artigos são leitura essencial. O terceiro artigo estabeleceu a base para o desenvolvimento de 
redes sem fios, incluindo o 802.11. 


Metcalf, R.; Boggs, D. Ethernet: Distributed packet switching for local computer networks. Communications of the ACM, 
v. 19, n. 7, p. 395-403, julho de 1976. 

Boggs, D.; Mogul, J.; Kent, C. Measured capacity of an Ethernet. Proceedings of the SIGCOMM '88 Symposium, p. 222-34, 
agosto de 1988. 

Bharghavan, V.; Demers, A.; Shenker, S.; Zhang, L. MACAW: a media access protocol for wireless LANs. Proceedings of the 
SIGCOMM '94 Symposium, p. 212-25, agosto de 1994. 


Existem inúmeros livros-texto com uma forte ênfase nos níveis mais baixos da hierarquia de rede, 
com um foco particular nas telecomunicações — as redes do ponto de vista da companhia telefônica. 
Os livros de Spragins et al. [SHP91] e Minoli [Min93] são dois bons exemplos. Vários outros livros se 
concentram em diversas tecnologias de rede local. Destas, o livro de Stallings é o mais abrangente 
[Sta00], enquanto Jain [Jai94] oferece uma boa introdução aos detalhes de baixo nível da comunicação 
óptica. 

A utilização de redes sem fios é uma área de pesquisa bastante ativa, com muitos artigos novos e 
interessantes aparecendo a cada ano. O artigo de Gupta e Kumar[GKO00] estabelece a teoria por trás da 
capacidade das redes sem fios. Basagni et al. [BCGS04] oferecem uma boa introdução às redes sem fios 
ad hoc. Bicket et al. [BABMOS5] descrevem o experimento da rede de malha sem fios Roofnet, e Biswas e 
Morris [BM05] apresentam o EXOR, que rodava sobre a Roofnet. O último artigo foi um exemplo inicial 
do uso de informações de camada cruzada para melhorar o desempenho de uma rede sem fios. Um 
uso diferente das técnicas de camada cruzada para melhorar a vazão em face dos erros de bits é des- 
crito por Jamieson et al. [JB07]. Wong et al. [WYLB06] examinam o problema de como escolher a taxa 
de transmissão de dados correta considerando um equilíbrio entre a taxa de erros e a largura de banda 
em um canal sem fios. Katti et al. [KRH+ 06] estabeleceram a viabilidade do uso da codificação de rede 
para melhorar o desempenho das redes sem fios. 

Um livro recente de Xiao et al. [XCL10] analisa muitos aspectos das redes de sensores. Vasseur e 
Dunkels [VD10] oferecem uma visão prospectiva de como a “Internet das coisas” poderia se tornar 
uma realidade com a adoção de protocolos da Internet para interconectar sensores e outros objetos 
inteligentes. 

Para uma introdução à teoria da informação, o livro de Blahut é um bom ponto de partida [Bla87], 
juntamente com o artigo inicial de Shannon sobre capacidade do enlace [Sha48]. 
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Para uma introdução geral à matemática por trás dos códigos de erros, é recomendada a leitura de 
Rao e Fujiwara RF89]. Para uma discussão detalhada da matemática dos CRCs em particular, juntamente 
com mais algumas informações sobre o hardware usado para calculá-los, consulte Peterson e Brown 
[PB61)]. 

Finalmente, recomendamos a seguinte referência viva: 


e hitp://standards.ieee.org/: situação de diversos padrões IEEE relacionados a redes, incluindo o 
Ethernet e o 802.11. 


Exercícios 


1. Mostre as codificações NRZ, Manchester e NRZI para o padrão de bits mostrado na Figura 2.36. 
Suponha que o sinal NRZI comece no nível baixo. 
2. Mostre a codificação 4B/5B e o sinal NRZI resultante para a seguinte sequência de bits: 


1110 0101 0000 0011 
3. Mostre a codificação 4B/5B e o sinal NRZI resultante para a seguinte sequência de bits: 
1101 1110 1010 1101 1011 1110 1110 1111 


4. Na codificação 4B/5B (Tabela 2.2) somente dois dos códigos de 5 bits usados terminam com dois 
Os. Quantas sequências de 5 bits possíveis existem (usadas pelo código existente ou não) que 
satisfazem a restrição mais forte de ter no máximo um 0 inicial e no máximo um 0 final? Todas as 
sequências de 4 bits poderiam ser mapeadas para essas sequências de 5 bits? 

5. Considerando um protocolo de enquadramento que usa preenchimento de bits, mostre a 
sequência de bits transmitida pelo enlace quando o quadro contém a seguinte sequência de bits: 


110101111101011111101011111110 


Marque os bits preenchidos. 
6. Considere que a seguinte sequência de bits chega por um enlace: 


1101011111010111110010111110110 


Mostre o quadro resultante depois que quaisquer bits preenchidos tiverem sido removidos. 
Indique quaisquer erros que poderiam ter sido introduzidos no quadro. 
7. Considere que a seguinte sequência de bits chega por um enlace: 


011010111110101001111111011001111110 


Mostre o quadro resultante depois que quaisquer bits preenchidos tiverem sido removidos. 
Indique quaisquer erros que poderiam ter sido introduzidos no quadro. 

8. Suponha que você queira enviar alguns dados usando o protocolo de enquadramento BISYNC 
e os 2 últimos bytes dos seus dados são DLE e ETX. Que sequência de bytes seria transmitida 
imediatamente antes do CRC? 
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Para cada um dos seguintes protocolos de enquadramento, dê um exemplo de uma sequência de 

bytes/bits que nunca deverá aparecer em uma transmissão: 

a. BISYNC 

b. HDLC 

Suponha que um receptor SONET ressincronize seu relógio sempre que um bit 1 aparece; caso 

contrário, o receptor faz a amostragem do sinal no meio do que ele acredita ser o slot de tempo 

do bit. 

a. Que precisão relativa dos relógios do emissor e do receptor é necessária para receber corretamente 
48 bytes de valor zero (tamanho correspondente a uma célula ATM) em sequência? 

b. Considere uma estação de encaminhamento A em uma linha SONET STS-1, recebendo 
quadros da extremidade B mais à frente no enlace e retransmitindo-os no sentido inverso. 
Que precisão relativa dos relógios de A e B é necessária para impedir que A acumule mais 
de um quadro extra por minuto? 

Mostre que a paridade bidimensional permite a detecção de todos os erros de 3 bits. 

Dê um exemplo de um erro de 4 bits que não seria detectado pela paridade bidimensional, 

conforme ilustrado na Figura 2.14. Qual é o conjunto geral de circunstâncias sob as quais 

os erros de 4 bits não serão detectados? 

Mostre que a paridade bidimensional fornece ao receptor informações suficientes para corrigir 

qualquer erro de 1 bit (supondo que o receptor saiba que apenas 1 bit está errado), mas 

não qualquer erro de 2 bits. 

Mostre que a soma de verificação da Internet nunca será 0xFFFF (ou seja, o valor final de sum 

não será 0x0000) a menos que cada byte no buffer seja 0. (As especificações da Internet de fato 

exigem que uma soma de verificação 0x0000 seja transmitida como 0xFFFF; o valor 0x0000 

é então reservado para uma soma de verificação omitida. Observe que, na aritmética 

de complemento de um, 0x0000 e 0xFFFF são representações do número 0.) 

Prove que o cálculo da soma de verificação da Internet mostrado no texto é independente 

da ordem dos bytes (ordem original no host ou ordem transmitida na rede), exceto que os bytes 

na soma de verificação final devem ser invertidos mais tarde para que fiquem na ordem correta. 

Especificamente, mostre que a soma de palavras de 16 bits pode ser calculada por qualquer 

ordem de bytes. Por exemplo, se a soma em complemento de um (denotada por +”) de palavras 

de 16 bits for representada da seguinte forma: 


[A,BI+'[C,D]+"...+'[Y,Z] 
a seguinte soma trocada tem o mesmo valor que a soma original acima: 
[B, A+ [D,C]+'...+'[Z,Y] 


Suponha que um byte em um buffer coberto pelo algoritmo de soma de verificação da Internet 
precise ser decrementado (por exemplo, um campo de contador de saltos no cabeçalho). 
Descreva um algoritmo para calcular a nova soma de verificação sem varrer novamente o buffer 
inteiro. Seu algoritmo deverá considerar se o byte em questão é de baixa ordem ou de alta ordem. 
Mostre que a soma de verificação da Internet pode ser calculada primeiro tomando-se a soma 
em complemento de um com 32 bits do buffer em unidades de 32 bits, depois tomando-se a 
soma em complemento de um com 16 bits das meia-palavras de odem mais alta e de ordem 
mais baixa, e terminando como antes, complementando o resultado. (Para calcular a soma em 
complemento de um com 32 bits usando um hardware que opera usando de complemento de 
dois com 32 bits, você precisa acessar o bit de “vai-um”.) 
Suponha que queiramos transmitir a mensagem 11100011 e protegê-la contra erros usando o 
polinômio de CRC xº+1. 
a. Use a divisão polinomial longa para determinar a mensagem que deve ser transmitida. 
b. Suponha que o bit mais à esquerda da mensagem esteja invertido devido a ruído no enlace 
de transmissão. Qual é o resultado do cálculo do CRC no receptor? Como o receptor sabe que 
houve um erro? 
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Suponha que queiramos transmitir a mensagem 1011 0010 0100 1011 e protegê-la contra erros 
usando o polinômio CRC8 


x? +x’ +x +l. 


a. Use a divisão polinomial longa para determinar a mensagem que deverá ser transmitida. 

b. Suponha que o bit mais à esquerda da mensagem seja invertido devido ao ruído no enlace 
durante a transmissão. Qual é o resultado do cálculo do CRC no receptor? Como o receptor 
sabe que houve um erro? 

O algoritmo de CRC apresentado neste capítulo requer muitas manipulações de bits. Porém, 

é possível realizar a divisão polinomial longa usando vários bits de cada vez, através de um 

método controlado por tabela, que permite implementações de software eficientes do CRC. 

Esboçamos a estratégia aqui para a divisão longa com 3 bits de cada vez (ver Tabela 2.5); na 

prática, dividiríamos 8 bits de cada vez, e a tabela teria 256 entradas. 

Considere que o polinômio divisor C= C(x) seja xº+x?+ 1, ou 1101. Para montar a tabela para 

C, tomamos cada sequência de 3 bits, p, anexamos três Os no final e depois determinamos o 

quociente q=p"000 + C, 

ignorando o resto. A terceira coluna é o produto Cx q, sendo que os três primeiros bits são 

iguais a p. 

a. Verifique, para p= 110, que os quocientes p"000 + Ce p°111 + C são iguais; ou seja, não 
importa quais sejam os bits finais. 

b. Preencha as entradas que faltam na tabela. 

c. Use a tabela para dividir 101 001 011 001 100 por C. Dica: Os 3 primeiros bits do dividendo são 
p=101, de modo que, pela tabela, os 3 primeiros bits correspondentes do quociente são q=110. 
Escreva o 110 acima dos próximos 3 bits do dividendo e subtraia Cx q = 101 110, novamente 
pela tabela, dos 6 primeiros bits do dividendo. Continue em grupos de 3 bits. Não deverá haver 
resto. 

Com 1 bit de paridade, podemos detectar todos os erros de 1 bit. Mostre que pelo menos uma 

generalização falha, da seguinte forma: 

a. Mostre que, se as mensagens m tiverem 8 bits de comprimento, então não existe um código 
de detecção de erro e=e(m) com tamanho de 2 bits que possa detectar todos os erros de 
2 bits. Dica: Considere o conjunto M de todas as mensagens de 8 bits com um único bit 1; 
observe que qualquer mensagem de M pode ser transmutada para qualquer outra com um 
erro de 2 bits, e mostre que algum par de mensagens m e m, em M precisa ter o mesmo 
código de erro e. 

b. Encontre um N (não necessariamente mínimo) tal que nenhum código de detecção de 
erros de 32 bits aplicado a blocos de N bits seja capaz de detectar todos os erros alterando 
até 8 bits. 

Considere um protocolo ARQ que usa apenas confirmações negativas (NAKs), mas não 

confirmações positivas (ACKs). Descreva quais temporizadores teriam que ser programados 

para expirar. Explique por que um protocolo baseado em ACK normalmente é preferível a um 
protocolo baseado em NAK. 


Tabela 2.5 Cálculo de CRC controlado por tabela 





p q = p"000 + C Cxq 
000 000 000 000 
001 001 001 101 
010 011 010. 
011 0. oi 
100 111 100 011 
101 110 101 110 
110 100 110 __ 
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Considere um algoritmo ARQ sendo executado em um enlace de fibra ponto a ponto com 40 km. 

a. Calcule o atraso de propagação unidirecional para esse enlace, supondo que a velocidade da 
luz seja 2 x 10m/s na fibra. 

b. Sugira um valor de expiração de temporizador adequado para ser utilizado pelo algoritmo 
ARQ. 

c. Por que ainda seria possível que o temporizador do algoritmo ARQ expirasse e um quadro 
fosse retransmitido, dado esse valor do tempo de expiração? 

Suponha que você esteja projetando um protocolo de janela deslizante para um enlace ponto 

a ponto de 1 Mbps até a lua, que tem uma latência de ida de 1,25 segundo. Supondo que cada 

quadro transporte 1 KB de dados, qual é o número mínimo de bits que você precisa usar para o 

número de sequência? 

Suponha que você esteja projetando um protocolo de janela deslizante para um enlace ponto 

a ponto de 1 Mbps até o satélite estacionário girando em torno da Terra a uma altitude de 

3 x 10! km. Supondo que cada quadro transporta 1 KB de dados, qual é o número mínimo de bits 

que você precisa usar para o número de sequência nos casos a seguir? Suponha que a velocidade 

da luz seja 3 x 108 m/s. 

a. RWS=1 

b. RWS=SWS 

O texto sugere que o protocolo de janela deslizante pode ser usado para implementar 

controle de fluxo. Podemos imaginar que isso pode ser feito forçando o receptor a atrasar 

ACKs, ou seja, não enviar o ACK até que haja espaço livre no buffer para acomodar o próximo 

quadro. Fazendo isso, cada ACK simultaneamente confirmaria o recebimento do último 

quadro e diria à origem que agora existe espaço livre no buffer disponível para acomodar o 

próximo quadro. Explique por que a implementação do controle de fluxo dessa maneira não é 

uma boa ideia. 

Implícita nos cenários parar e esperar da Figura 2.17 está a noção de que o receptor retransmitirá 

seu ACK imediatamente ao receber o quadro de dados duplicado. Suponha que, ao invés disso, 

o receptor mantenha seu próprio temporizador e retransmita seu ACK somente depois que o 

próximo quadro esperado não tiver chegado dentro do intervalo de expiração. Desenhe linhas 

de tempo ilustrando os cenários da Figura 2.17(b) a (d); suponha que o valor do intervalo de 

expiração do receptor seja o dobro do valor do emissor. Além disso, redesenhe (c) supondo que o 

valor do intervalo de expiração do receptor seja metade do valor do emissor. 

Na transmissão parar e esperar, suponha que tanto o emissor quanto o receptor 

retransmitam seu último quadro imediatamente no recebimento de um ACK duplicado ou 

quadro de dados duplicado; essa estratégia é superficialmente razoável, pois o recebimento 
de tal duplicata provavelmente significaria que houve uma expiração de temporizador no 
outro lado. 

a. Desenhe uma linha de tempo mostrando o que acontecerá se o primeiro quadro 
de dados de alguma forma for duplicado, mas nenhum quadro for perdido. Por quanto 
tempo as duplicações continuarão? Essa situação é conhecida como bug do Aprendiz de 
Feiticeiro. 

b. Suponha que, assim como os dados, os ACKs sejam retransmitidos se não houver resposta 
dentro do período de expiração do temporizador. Suponha também que os dois lados usam o 
mesmo intervalo de expiração. Identifique um cenário razoavelmente provável para disparar 
o bug do Aprendiz de Feiticeiro. 

Forneça alguns detalhes de como você poderia aumentar o protocolo da janela deslizante com 

controle de fluxo, fazendo com que os ACKs transportem informações adicionais que reduzam 

o valor de SWS quando o receptor ficar sem espaço em buffer. Ilustre seu protocolo com uma 

linha de tempo para uma transmissão; suponha que os valores iniciais de SWS e RWS seja 4, 

a velocidade do enlace seja instantânea e o receptor possa liberar os buffers na velocidade de 

um por segundo (ou seja, o receptor é o gargalo). Mostre o que acontece em T=0, T=1,..., T=4 

segundos. 
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Descreva um protocolo combinando o algoritmo de janela deslizante com ACKs seletivos. Seu 

protocolo deverá retransmitir prontamente, mas não se um quadro simplesmente chegar uma 
ou duas posições fora de ordem. Seu protocolo também deverá deixar explícito o que acontece 
se vários quadros consecutivos forem perdidos. 


. Desenhe um diagrama de linha de tempo para o algoritmo de janela deslizante com 


SWS=RWS=3 quadros, mas para as duas situações a seguir. Use um intervalo de expiração de 

temporizador de cerca de 2 x RTT. 

a. Quadro 4 é perdido. 

b. Quadros 4 a 6 são perdidos. 

Desenhe um diagrama de linha de tempo para o algoritmo de janela deslizante com SWS=RWS=4 

quadros nas duas situações a seguir. Suponha que o receptor envia uma confirmação duplicada se 

não receber o quadro esperado. Por exemplo, ele envia DUPACK|2] quando esperar ver Quadro[2] 
mas recebe Quadro[3] em seu lugar. Além disso, o receptor envia uma confirmação cumulativa 
após receber todos os quadros pendentes. por exemplo, ele envia ACK[5] quando recebe o quadro 
perdido Quadro[2] depois que já tiver recebido Quadro [3], Quadro [4] e Quadro [5]. Use um 
intervalo de expiração de temporizador de cerca de 2 x RTT. 

a. O quadro 2 é perdido. A retransmissão ocorre na expiração do temporizador (como de costume). 

b. O quadro 2 é perdido. A retransmissão ocorre ou no recebimento do primeiro DUPACK ou 
na expiração do temporizador. Esse esquema reduz o tempo da transação? (Observe que 
alguns protocolos fim a fim, como variantes do TCP utilizam esquemas semelhantes para 
retransmitir rapidamente.) 

Suponha que tentemos executar o algoritmo de janela deslizante com SWS=RWS=3 e com 

MaxSegNum=5. O enésimo pacote DATA[N], portanto, na realidade contém N mod 5 em seu 

campo de número de sequência. Mostre um exemplo em que o algoritmo se confunde; ou seja, 

um cenário em que o receptor espera DATA[5] e aceita DATA[0] — que tem o mesmo número de 
sequência transmitido — em seu lugar. Nenhum pacote pode chegar fora de ordem. Observe que 
isso implica que MaxSeqNum > 6 é necessário e também suficiente. 

Considere o algoritmo de janela deslizante com SWS = RWS =3, sem chegadas fora de ordem e 

com números de sequência com precisão infinita. 

a. Mostre que, se DATA[6] estiver na janela de recepção, então DATA[0] (ou, de forma geral, 
qualquer dado mais antigo) não poderá chegar no receptor (e por isso MaxSegNum=6 seria 
suficiente). 

b. Mostre que, se ACK[6] puder ser enviado (ou, mais literalmente, que DATA[5] está na janela de 
envio), então ACK[2] (ou um anterior) não poderá ser recebido. 

Isso corresponde a uma prova da fórmula dada na Seção 2.5.2, particularizada para o caso 

SWS=3. Observe que a parte (b) implica que o cenário do problema anterior não pode ser 

revertido de modo a envolver uma falha na tentativa de distinguir ACK[0] e ACK[5]. 

Suponha que executemos o algoritmo de janela deslizante com SWS =5 e RWS=3, e nenhuma 

chegada fora de ordem. 

a. Determine o valor mínimo de MaxSegNum. Você pode considerar que é suficiente determinar o 
menor MaxSeqNum tal que, se DATA[MaxSeqNum] estiver na janela de recepção, então DATA[0] 
não pode mais chegar. 

b. Forneça um exemplo mostrando que MaxSeqNum — 1 não é suficiente. 

c. Indique uma regra geral para o MaxSeqNum mínimo em termos de SWS e RWS. 

Suponha que A esteja conectado a B por meio de um roteador intermediário R, como mostra a 

Figura 2.37. Os enlaces A-R e R-B aceitam e transmitem cada um apenas um pacote por segundo 

em cada direção (de modo que dois pacotes levam 2 segundos) e as duas direções transmitem de 

forma independente. Suponha que A envie dados para B usando o protocolo de janela deslizante 
com SWS=4. 


(A) (R) (B) FIGURA 2.37 Diagrama para os Exercícios de 36 a 38. 
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a. Para Tempo =0, 1, 2, 3, 4, 5, indique quais pacotes chegam e saem de cada nó, ou rotule-os em 
uma linha de tempo. 

b. O que acontece se os enlaces têm um atraso de propagação de 1,0 segundo, mas aceitam 
imediatamente tantos pacotes quantos forem fornecidos (ou seja, latência = 1 segundo, mas a 
largura de banda é infinita)? 

Suponha que A esteja conectado a B por meio de um roteador intermediário R, como no 

problema anterior. O enlace A-R é instantâneo, mas o enlace R-B transmite apenas um pacote 

a cada segundo, um de cada vez (de modo que dois pacotes levam 2 segundos). Suponha que 

A envia dados para B usando o protocolo de janela deslizante com SWS =4. Para Tempo=0, 1, 

2, 3, 4, indique quais pacotes chegam e são enviados de A e B. Qual tamanho a fila em R pode 

atingir? 

Considere a situação do exercício anterior, exceto que desta vez considere que o roteador tenha 

um tamanho de fila iguala 1; ou seja, ele pode armazenar um pacote além daquele que está 

enviando (em cada direção). Considere que o tempo de expiração do temporizador de A seja 

5 segundos, e considere que SWS novamente seja 4. Mostre o que acontece em cada segundo 

desde Tempo =0 até que todos os quatro pacotes desde a primeira janela cheia sejam entregues 

com sucesso. 

Que tipos de problemas podem surgir quando dois hosts na mesma Ethernet compartilham o 

mesmo endereço de hardware? Descreva o que acontece e por que esse comportamento é um 

problema. 

A especificação do Ethernet de 1982 permitia, entre duas estações quaisquer, até 1.500 m de 

cabo coaxial, 1.000 m de outro cabo de ligação ponto a ponto e dois repetidores. Cada estação 

ou repetidor se conecta ao cabo coaxial por meio de até 50 m de “cabo transceptor”. Atrasos 
típicos associados a cada dispositivo são dados na Tabela 2.6 (onde c=velocidade da luz no 
vácuo=3 x 108m/s). Qual é o pior cenário de um atraso de propagação de ida e volta, medido 

em bits, devido às fontes listadas? (Essa lista não é completa; outras fontes de atraso incluem o 

tempo de detecção e o tempo de subida do sinal.) 

As redes Ethernet com cabo coaxial eram limitadas a um máximo de 500 m entre repetidores, 

que regeneram o sinal a 100% de sua amplitude original. Ao longo de um segmento de 500 m, o 

sinal poderia decair para não menos do que 14% de seu valor original (8,5 dB). Ao longo de 1.500 

m, portanto, a queda poderia ser (0,14)º= 0,3%. Esse sinal, até mesmo ao longo de 2.500 m, ainda 

é forte o suficiente para ser lido; por que, então, os repetidores são exigidos a cada 500 m? 

Suponha que a propagação do atraso de ida e volta para o Ethernet seja de 46,4 ms. Isso gera um 

tamanho de pacote mínimo de 512 bits (464 bits correspondentes ao atraso de propagação + 48 

bits de sinal de jamming). 

a. O que acontece com o tamanho mínimo de pacote se o tempo de atraso for mantido 
constante e a taxa de sinalização subir para 100 Mbps? 

b. Quais são as desvantagens de um tamanho mínimo de pacote tão grande? 

c. Sea compatibilidade não fosse um problema, como as especificações poderiam ser escritas 
de modo a permitir uma redução no tamanho mínimo de pacote? 

Considere que A e B sejam duas estações tentando transmitir dados em uma rede Ethernet. Cada 

uma tem uma fila constante de quadros prontos para enviar; os quadros de A serão numerados 

com A,, 4, e assim por diante, e os de B de forma semelhantes. Considere que T=51,2 us seja a 

unidade básica do recuo exponencial. 


Tabela 2.6 Atrasos típicos associados a diversos dispositivos (Exercício 40) 





Item Atraso 

Cabo coaxial Velocidade de propagação 0,77c 
Cabo transceptor Velocidade de propagação 0,65c 
Repetidores Aproximadamente 0,6 us cada 


Transceptores Aproximadamente 0,2 us cada 
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Suponha que A e B tentem simultaneamente enviar o quadro 1, colidam e escolham os tempos 
de recuo de 0 x Te 1 x T, respectivamente, significando que A vence a corrida e transmite A, 
enquanto B espera. Ao final dessa transmissão, B tentará retransmitir B,, enquanto A tentará 
transmitir 4,. Essas primeiras tentativas colidirão, mas agora A abstem-se de enviar por um 
período que pode ser igual a 0 x Tou 1 x T, enquanto o tempo de recuo de B pode assumir 

um valor dentre 0x T, ..., 3 X T. 

a. Calcule a probabilidade de que A vença essa segunda corrida de recuo imediatamente depois 
dessa primeira colisão; ou seja, a probabilidade de que a primeira escolha de A para o tempo 
de recuo k x 51,2 seja menor do que a de B. 

b. Suponha que A vença essa segunda corrida de recuo. A transmite A; e, quando tiver 
terminado, A e B colidem novamente enquanto A tenta transmitir A, e B tenta mais uma 
vez transmitir B,. Calcule a probabilidade de que A vença essa terceira corrida de recuo 
imediatamente após a primeira colisão. 

c. Calcule um limite inferior razoável para a probabilidade de que A vença todas as corridas de 
recuo restantes. 

d. O que, então, acontece com o quadro B;? 

Esse cenário e conhecido como o efeito de captura da rede Ethernet. 

Suponha que o algoritmo de transmissão da rede Ethernet seja modificado da seguinte forma. 

Depois de cada tentativa de transmissão bem-sucedida, um host espera um ou dois slots de 

tempo antes de tentar transmitir novamente, e caso contrário recua da forma normal. 

a. Explique por que o efeito de captura do exercício anterior agora é muito menos provável. 

b. Mostre como a estratégia acima pode agora levar a um par de hosts capturando a rede 
Ethernet, alternando transmissões e bloqueando um terceiro. 

c. Proponha uma técnica alternativa, por exemplo, modificando o mecanismo de recuo 
exponencial. Que aspectos do histórico de uma estação poderiam ser usados como 
parâmetros para o mecanismo de recuo modificado? 

Redes Ethernet usam a codificação Manchester. Supondo que os hosts compartilhando a rede 

Ethernet não sejam perfeitamente sincronizados, por que isso permite que as colisões sejam 

detectadas logo depois que elas ocorram sem esperar pelo CRC ao final do pacote? 

Suponha que A, B e C realizem sua primeira detecção de portadora, como parte de uma tentativa 

de transmitir, enquanto uma quarta estação D está transmitindo. Desenhe uma linha de tempo 

mostrando uma sequência possível de escolhas de transmissões, tentativas, colisões e recuo 
exponencial. Sua linha de tempo também deverá satisfazer os seguintes critérios: (i) tentativas de 
transmissão iniciais devem estar na ordem A, B, C, mas as transmissões bem-sucedidas deverão 
estar na ordem C, B, A e (ii) deverão haver pelo menos quatro colisões. 

Repita o exercício anterior, agora supondo que a rede Ethernet seja p-persistente com p=0,33 

(ou seja, uma estação esperando transmite imediatamente com probabilidade p quando a 

linha fica ociosa e, caso contrário, adia a transmissão por um slot de tempo de 51,2 us e repete o 

processo). Sua linha de tempo deverá satisfazer o critério (i) do problema anterior, mas no lugar 

do critério (ii), você deverá mostrar pelo menos uma colisão e pelo menos uma execução de 
quatro adiamentos de envio em caso de uma linha ociosa. 

Suponha que os endereços físicos das redes Ethernet sejam escolhidos aleatoriamente (usando 

bits verdadeiramente aleatórios). 

a. Qual é a probabilidade de que, em uma rede com 1.024 hosts, dois endereços sejam iguais? 

b. Qual é a probabilidade de que o evento acima ocorra em uma ou mais dentre 22º redes? 

c. Qual é a probabilidade de que, dos 2% hosts em todas as redes de (b), algum par tenha o 
mesmo endereço? 

Dica: O cálculo para os itens (a) e (c) é uma variante daquele usado na solução do chamado 

Problema do Aniversário: Com N pessoas, qual é a probabilidade de que duas de suas datas de 

nascimento (endereços) sejam iguais? A segunda pessoa tem probabilidade a de ter uma 

data de nascimento diferente da primeira, a terceira tem probabilidade 1-4 de ter uma data de 
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nascimento diferente das duas primeiras, e assim por diante. A probabilidade de que todas as 
datas de nascimento sejam diferentes é, portanto, 


1 2 NI 
-— | x|l-— |x- x| l1-—— 
| E] A | s) 


que para um N muito pequeno é cerca de 


1+2+--:-+(N-—1) 
365 


Suponha que cinco estações estejam esperando que a transmissão de outro pacote termine em 
uma rede Ethernet. Todas as estações transmitem ao mesmo tempo quando o envio do pacote 
termina e colidem. 

a. Simule essa situação até o ponto em que uma das cinco estações aguardando tenha sucesso. 
Use lançamentos de moedas ou alguma outra fonte genuinamente aleatória para determinar 
os tempos de recuo. Faça as seguintes simplificações: ignore o espaçamento entre quadros, 
ignore a variabilidade nos tempos de colisão (de modo que a retransmissão sempre ocorra 
após um múltiplo inteiro exato do tempo de slot de 51,2 us) e considere que cada colisão 
utiliza exatamente um slot de tempo. 

b. Discuta o efeito das simplificações listadas na sua simulação contra o comportamento que 
você poderia encontrar em uma rede Ethernet real. 

Escreva um programa para implementar a simulação discutida acima, desta vez com N estações 

esperando para transmitir. Novamente, modele o tempo como um inteiro, T, em unidades de 

tempos de slot, e novamente considere que as colisões ocupam um slot de tempo (de modo 
que uma colisão no instante T seguida por um recuo de k=0 resultaria em uma tentativa de 
retransmissão no instante T + 1). Determine o atraso médio antes que uma estação transmita 

com sucesso, para N=20, N=40 e N= 100. Seus dados dão suporte à noção de que o atraso é 

linear em N? Dica: Para cada estação, registre o NextTimeToSend e o CollisionCount dessa estação. 

Você pode interromper o processo quando atingir o instante T para o qual existe apenas uma 

estação com NextTimeToSend=T. Se não houver tal estação, incremente T. Se houver duas ou 

mais, programe o tempo das retransmissões e tente novamente. 

Suponha que N estações Ethernet, todas tentando enviar ao mesmo tempo, precisem de N/2 

slots de tempo para descobrir quem transmitirá em seguida. Supondo que o tamanho médio do 

pacote seja de 5 slots de tempo, expresse a largura de banda disponível como uma função de N. 

Considere o seguinte modelo Ethernet. As tentativas de transmissão ocorrem em momentos 

aleatórios com um espaçamento médio de à slots de tempo; especificamente, o intervalo entre 

as tentativas consecutivas é uma variável aleatória exponencial x=- log u, onde u é escolhido 
aleatoriamente no intervalo 0 < u < 1. Uma tentativa no instante t resulta em uma colisão se 
houver outra tentativa no intervalo de t- 1 a t+ 1, onde t é medido em unidades de slot de tempo 
de 51,2 us; caso contrário, a tentativa tem sucesso. 

a. Escreva um programa para simular, para determinado valor de à, o número médio de slots 
de tempo necessários antes de haver uma transmissão bem sucedida, chamado intervalo de 
contenção. Determine o valor mínimo do intervalo de contenção. Observe que você terá que 
encontrar uma tentativa além daquela que teve sucesso a fim de determinar se houve uma 
colisão. Ignore as retransmissões, que provavelmente não se adequam ao modelo aleatório 
apresentado. 

b. Arede Ethernet alterna entre os intervalos de contenção e as transmissões bem sucedidas. 
Suponha que a transmissão bem sucedida média dure 8 slots de tempo (512 bytes). usando 
seu tamanho mínimo do intervalo de contenção determinado no item (a), que fração da 
largura de banda teórica de 10 Mbps está disponível para transmissões? 

Como um nó sem fios interfere com as comunicações de outro nó quando os dois nós estão 

separados por uma distância maior do que o intervalo de transmissão de qualquer nó? 
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54. 


55. 
56. 


57. 


Por que a detecção de colisão é mais complexa nas redes sem fios do que nas redes com fios, 
como redes Ethernet? 

Como os terminais ocultos podem ser detectados nas redes 802.112 

Por que uma topologia de malha sem fios poderia ser superior a uma topologia de estação base 
para as comunicações em caso de um desastre natural? 

Por que não é prático que cada nó em uma rede de sensores descubra sua localização usando 
GPS? Descreva uma alternativa prática. 


Interconexão de redes 


A natureza parece... alcançar muitos de seus fins por longas rotas tortuosas. 
Rudolph Lotze 


E E Problema: nem todas as redes estão diretamente conectadas E 


No capítulo anterior, vimos como conectar um nó a outro ou a uma rede existente. Muitas 
tecnologias podem ser usadas para montar os enlaces de “última milha” ou para conectar um 
número modesto de nós, mas como montamos redes de escala global? Uma única Ethernet não 
pode interconectar mais de 1.024 hosts; um enlace ponto a ponto conecta apenas dois. As redes 
sem fios são limitadas pelo alcance de seus rádios. Para montar uma rede global, precisamos achar 
um modo de interconectar esses diferentes tipos de enlaces e redes. O conceito de interconexão 
de diferentes tipos de redes para montar uma rede grande, global, é a ideia central da Internet, 
sendo normalmente chamada de interconexão de redes (ou internetworking). 

Podemos dividir o problema da interconexão de redes em alguns subproblemas. Em 

primeiro lugar, precisamos encontrar um modo de interconectar enlaces. Os dispositivos 

que interconectam enlaces do mesmo tipo normalmente são chamados de switches, e esses 
dispositivos são o primeiro tópico deste capítulo. Uma classe particularmente importante de 
switches, hoje, são aqueles usados para interconectar segmentos Ethernet; esses switches, às vezes, 
também são chamados de bridges (pontes). A tarefa principal de um switch é tomar os pacotes 
que chegam em uma entrada e encaminhá-los (ou comutá-los) para a saída correta, de modo que 
alcancem seu destino apropriado. Existe uma grande variedade de maneiras como o switch pode 
determinar a saída “correta” para um pacote, que podem ser categorizadas de modo geral como 
técnicas sem conexão e orientadas a conexão. Essas duas técnicas encontraram importantes áreas 
de aplicação com o passar dos anos. 

Dada a enorme diversidade dos tipos de rede, também precisamos achar um modo de 
interconectar redes e enlaces díspares (ou seja, lidar com a heterogeneidade). Os dispositivos que 
realizam essa tarefa, outrora chamados gateways, agora são conhecidos principalmente como 
roteadores. O protocolo que foi inventado para lidar com a interconexão de tipos de rede díspares, 
o Internet Protocol (IP), é o assunto da nossa segunda seção. 

Quando interconectamos diversos enlaces e redes com switches e roteadores, provavelmente 
existem muitas maneiras diferentes de passar de um ponto para outro. Encontrar um caminho 
adequado ou rotear por meio de uma rede é um dos problemas fundamentais das redes. Esses 
caminhos deverão ser eficientes (por exemplo, não maiores do que o necessário), sem ciclos, e 
capazes de responder ao fato de que as redes não são estáticas — os nós podem falhar ou reiniciar, 
enlaces podem se partir e novos nós ou enlaces podem ser acrescentados. Nossa terceira seção 
examina alguns dos algoritmos e protocolos que foram desenvolvidos para resolver essas 
questões. 

Após entendermos os problemas de comutação e roteamento, precisaremos de alguns 
dispositivos para realizar essas funções. Este capítulo conclui com uma breve discussão sobre as 
maneiras como os switches e roteadores são construídos. Embora muitos switches e roteadores 
de pacotes sejam muito semelhantes a um computador de uso geral, existem muitas situações em 
que são usados projetos mais especializados. Isso acontece particularmente no caso de aplicações 
de ponta, onde parece haver uma necessidade sem-fim de roteadores maiores e mais rápidos para 
lidar com a carga de tráfego cada vez maior no núcleo da Internet. 
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3.1 Comutação e pontes A 


LANs comutadas 
Em termos extremamente simples, um switch é um mecanismo que nos permite interconectar enlaces 
para formar uma rede maior. Um switch é um dispositivo com múltiplas entradas e múltiplas saídas, que 
transfere pacotes de uma entrada para uma ou mais saídas. Assim, um switch acrescenta a topologia em 
estrela (ver Figura 3.1) às tipologias de enlace ponto a ponto, barramento (Ethernet) e anel, discutidas 
no capítulo anterior. Uma topologia em estrela tem várias propriedades atraentes: 


e Embora um switch tenha um número fixo de entradas e saídas, o que limita o número de 
hosts que podem ser conectados a um único switch, grandes redes podem ser montadas 
interconectando uma série de switches. 

e Podemos conectar switches uns aos outros e aos hosts usando enlaces ponto a ponto, o que 
normalmente significa que podemos montar redes com um escopo geográfico grande. 

e Ainclusão de um novo host à rede por meio de sua conexão a um switch não necessariamente 
reduz o desempenho da rede para outros hosts já conectados. 


Essa última afirmação não pode ser feita para redes cujo meio é compartilhado, discutidas no 
capítulo anterior. Por exemplo, é impossível que dois hosts no mesmo segmento Ethernet de 10 Mbps 
transmitam continuamente a 10 Mbps, pois eles compartilham o mesmo meio de transmissão. Cada 
host em uma rede comutada tem seu próprio enlace com o switch, de modo que é totalmente possível 
que muitos hosts transmitam dados na velocidade (largura de banda) máxima do enlace, desde que 
o switch seja projetado com capacidade agregada suficiente. Fornecer uma alta vazão agregada é um 
dos objetivos de projeto para um switch; retornaremos a esse assunto mais tarde. Em geral, as redes 
comutadas são consideradas mais escaláveis (ou seja, mais capazes de crescer para englobar grandes 
quantidades de nós) do que as redes cujo meio é compartilhado, devido a essa capacidade de admitir 
muitos hosts operando na velocidade máxima. 

Um switch é conectado a um conjunto de enlaces e, para cada um desses enlaces, executa o pro- 
tocolo de enlace de dados apropriado para se comunicar com o nó na outra ponta do enlace. A tarefa 
principal de um switch é receber pacotes que chegam em um de seus enlaces e transmiti-los para algum 
outro enlace. Essa função às vezes é conhecida como comutação ou encaminhamento, e em termos da 
arquitetura Open Systems Interconnection (OSI), essa é a função principal da camada de rede. 

A questão, portanto, é: como o switch decide em qual enlace de saída ele colocará cada pacote? 
A resposta geral é que ele examina o cabeçalho do pacote em busca de um identificador que é usado 
para tomar tal decisão. Os detalhes de como ele usa esse identificador variam, mas existem duas técnicas 
comuns. A primeira é a técnica de datagrama ou sem conexão. A segunda é a técnica de circuito virtual 
ou orientada à conexão. Uma terceira técnica, o roteamento na origem, é menos comum do que essas 
outras duas, mas possui algumas aplicações úteis. 








FIGURA 3.1 Um switch oferece uma topologia em estrela. 
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Uma característica comum a todas as redes é que precisamos ter uma forma de identificar os nós 
finais. Esses identificadores normalmente são chamados de endereços. Já vimos exemplos de endere- 
ços no capítulo anterior, como o endereço de 48 bits usado pelo padrão Ethernet. O único requisito 
para endereços Ethernet é que dois nós em uma rede não podem ter o mesmo endereço. Isso é feito 
garantindo-se que todas as placas Ethernet recebam um identificador globalmente exclusivo. Para as 
discussões a seguir, consideramos que cada host tem um endereço globalmente exclusivo. Mais adiante, 
consideramos outras propriedades úteis que um endereço poderia ter, mas a exclusividade global é 
adequada para começarmos. 

Outra suposição que precisamos fazer é que existe alguma maneira de identificar as portas de en- 
trada e saída de cada switch. Existem pelo menos duas maneiras comuns de identificar portas: uma é 
numerar cada porta e a outra é identificar a porta pelo nome do nó (switch ou host) ao qual ele leva. 
Por enquanto, usaremos a numeração das portas. 


3.1.1 Datagramas 


A ideia por trás dos datagramas é incrivelmente simples: você só inclui em cada pacote informações 
suficientes para permitir que qualquer switch decida como fazer com que ele chegue ao seu destino. 
Ou seja, cada pacote contém o endereço de destino completo. Considere a rede de exemplo ilustrada 
na Figura 3.2, em que os hosts têm endereços A, B, C e assim por diante. Para decidir como encami- 
nhar um pacote, um switch consulta uma tabela de encaminhamento (também chamada de tabela de 
roteamento), com um exemplo aparecendo na Tabela 3.1. Essa tabela em particular mostra a informação 
de encaminhamento que o switch 2 precisa para encaminhar datagramas na rede de exemplo. É muito 
fácil determinar essa tabela quando você tem um mapa completo de uma rede simples, como aquela 
representada aqui; poderíamos imaginar um operador de rede configurando as tabelas de forma 
estática. É muito mais difícil criar as tabelas de encaminhamento em redes grandes e complexas, com 
topologias que mudam dinamicamente e têm vários caminhos entre os destinos. Esse problema mais 
difícil é conhecido como roteamento e é o assunto da Seção 3.3. Podemos imaginar o roteamento como 





Switch 3 


FIGURA 3.2 Encaminhamento de datagrama: uma rede de exemplo. 
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Tabela 3.1 Tabela de encaminhamento para o switch 2 


Destino Porta 





Too mora p 
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um processo que ocorre em segundo plano, de modo que, quando um pacote de dados aparece, temos 
a informação correta na tabela de encaminhamento para poder encaminhar ou comutar o pacote. 
As redes de datagramas possuem as seguintes características: 


e Um host pode enviar um pacote para qualquer lugar a qualquer momento, pois qualquer 
pacote que chega em um switch pode ser encaminhado imediatamente (considerando uma 
tabela de encaminhamento corretamente preenchida). Por esse motivo, as redes de datagramas 
normalmente são consideradas sem conexão; isso contrasta com as redes orientadas à conexão, 
descritas a seguir, em que algum estado de conexão precisa ser estabelecido antes que o primeiro 
pacote de dados seja enviado. 

e Quando um host envia um pacote, ele não tem como saber se a rede é capaz de entregá-lo nem se 
o host de destino está pronto e funcionando. 

e Cada pacote é encaminhado independentemente dos pacotes anteriores que poderiam ter sido 
enviados para o mesmo destino. Assim, dois pacotes sucessivos do host A para o host B podem 
seguir caminhos completamente diferentes (talvez por causa de uma mudança na tabela de 
encaminhamento em algum switch na rede). 

e Uma falha no switch ou no enlace poderia não ter qualquer efeito sério sobre a comunicação se 
for possível encontrar uma rota alternativa contornando o ponto de falha e atualizar a tabela de 
encaminhamento de modo correspondente. 


Esse último fato é particularmente importante para a história das redes de datagrama. Um dos 
objetivos de projeto importantes da Internet é a robustez a falhas, e a história tem mostrado que ela é 
muito eficaz ao cumprir esse objetivo.! 


3.1.2 Comutação de circuitos virtuais 


Outra abordagem para a comutação de pacotes, que difere bastante do modelo de datagramas, utiliza 
o conceito de um circuito virtual (VC — Virtual Circuit). Essa abordagem, que também é conhecida 
como modelo orientado à conexão, requer a configuração de uma conexão virtual do host de origem até 
o host de destino antes que qualquer dado seja enviado. Para entender como isso funciona, considere a 
Figura 3.3, onde o host A novamente deseja enviar pacotes para o host B. Podemos pensar nisso como 
um processo em dois estágios. O primeiro estágio é o “estabelecimento da conexão”. O segundo é a 
transferência dos dados. Vamos considerar um de cada vez. 

Na fase de estabelecimento de conexão, é preciso estabelecer um “estado da conexão” em cada um 
dos switches entre os hosts de origem e destino. O estado da conexão para uma única conexão consiste 
em uma entrada em uma “tabela de circuitos virtuais”, ou “tabela de VCs”, em cada switch pelo qual a 
conexão passa. Uma entrada na tabela de VCs em um único switch contém: 


1A alegação constantemente repetida de que a ARPANET foi montada para suportar um ataque nuclear parece não ser 
fundamentada por aqueles que realmente trabalharam em seu projeto, mas a robustez à falha de componentes individuais 
certamente foi um objetivo. 
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Switch 1 Switch 2 





Switch 3 mu 


Host A 


FIGURA 3.3 Exemplo de uma rede de circuito virtual. 


e Um identificador de circuito virtual (VCI — Virtual Circuit Identifier) que identifica exclusivamente 
a conexão nesse switch e que será colocado no cabeçalho dos pacotes que pertencem a essa 
conexão. 

e Uma interface de chegada na qual os pacotes desse VC chegam no switch. 

e Uma interface de saída na qual os pacotes desse VC saem do switch. 

e Um VCI potencialmente diferente que será usado para os pacotes que saem. 


A semântica de uma entrada desse tipo é a seguinte: se um pacote chega na interface de entrada 
designada e contém o valor do VCI designado em seu cabeçalho, então esse pacote deve ser enviado 
pela interface de saída especificada após o valor do VCI de saída especificado ter sido colocado em seu 
cabeçalho. 

Observe que a combinação do VCI dos pacotes que são recebidos no switch e da interface na qual eles 
são recebidos identifica univocamente a conexão virtual. Naturalmente, pode haver muitas conexões 
virtuais estabelecidas no switch em determinado momento. Além disso, observamos que os valores de 
VCI que chegam e saem geralmente não são os mesmos. Assim, o VCI não é um identificador globalmente 
significativo para a conexão; em vez disso, ele tem significado apenas em determinado enlace (ou seja, 
ele tem escopo local ao enlace). 

Sempre que uma nova conexão é criada, precisamos atribuir um novo VCI para essa conexão em cada 
enlace que a conexão atravessará. Também precisamos garantir que o VCI escolhido em determinado 
enlace não está atualmente em uso nesse enlace por alguma conexão existente. 

Existem duas técnicas gerais para estabelecer o estado da conexão. Uma é fazer com que o adminis- 
trador da rede configure o estado, e neste caso o circuito virtual será “permanente”. Naturalmente, ele 
também pode ser excluído pelo administrador, de modo que um circuito virtual permanente (PVC — 
Permanent Virtual Circuit) poderia ser imaginado mais corretamente como um VC de longa vida ou 
configurado administrativamente. Como alternativa, um host pode enviar mensagens para a rede para 
fazer com que o estado seja estabelecido. Isso é conhecido como sinalização, e os circuitos virtuais 
resultantes são denominados comutados. A característica de destaque de um circuito virtual comutado 
(SVC — Switched Virtual Circuit) é que um host pode estabelecer e remover esse VC dinamicamente 
sem o envolvimento de um administrador da rede. Observe que um SVC deveria ser chamado mais 
precisamente de VC sinalizado, pois é o uso da sinalização (não da comutação) que distingue um SVC 
de um PVC. 

Vamos supor que um administrador de rede queira criar manualmente uma nova conexão virtual 
do host A para o host B.? Primeiro, o administrador precisa identificar um caminho pela rede de A até 
B. Na rede de exemplo da Figura 3.3, há somente um caminho desse tipo, mas em geral isso pode não 


2Na prática, o processo provavelmente seria muito mais automatizado do que descrevemos aqui, talvez usando algum tipo 
de ferramenta gráfica de gerenciamento de rede. As etapas a seguir ilustram o estado que precisa ser estabelecido em qualquer 
caso. 
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Tabela 3.2 Entrada da tabela de circuitos virtuais para o switch 1 


Interface de entrada VCI de entrada Interface de saída VCI de saída 
2 5 1 11 





acontecer. O administrador, então, seleciona um valor de VCI que não esteja sendo usado no momento 
para cada enlace que fará parte da conexão. Para os propósitos do nosso exemplo, vamos supor que o 
valor 5 do VCI seja escolhido para o enlace do host A ao switch 1, e que 11 seja escolhido para o enlace 
do switch 1 ao switch 2. Nesse caso, o switch 1 precisa ter uma entrada em sua tabela de VCs configurada 
como mostrado a Tabela 3.2. 

De modo semelhante, suponha que o VCI 7 foi escolhido para identificar esta conexão no enlace do 
switch 2 para o switch 3 e que um VCI 4 foi escolhido para o enlace do switch 3 ao host B. Nesse caso, os 
switches 2 e 3 precisam ser configurados com entradas na tabela de VCs conforme mostrado na Tabela 3.3. 
Observe que o valor de VCI “de saída” em um switch é o valor do VCI “de entrada” no próximo switch. 

Quando as tabelas de VCs tiverem sido configuradas, pode-se prosseguir com a fase de transferência 
de dados, conforme ilustrado na Figura 3.4. Para qualquer pacote que queira enviar para o host B, A 
coloca o valor de VCI 5 no cabeçalho do pacote e o envia para o switch 1. O switch 1 recebe qualquer 
pacote desse tipo na interface 2 e usa a combinação da interface e do VCI no cabeçalho do pacote para 
encontrar a entrada apropriada na tabela de VCs. Como vemos na Tabela 3.2, a entrada da tabela, nesse 
caso, diz ao switch 1 para encaminhar o pacote pela interface 1 e colocar o valor de VCI 11 no cabeçalho 
quando o pacote for enviado. Assim, o pacote chegará no switch 2 pela interface 3 portando o VCI 11. 
O switch 2 procura pela entrada correspondente à interface 3 e ao VCI 11 em sua tabela de VCs (como 
mostrado na Tabela 3.3) e envia o pacote para o switch 3 depois de atualizar o valor do VCI no cabeçalho 
do pacote de forma apropriada, como mostrado na Figura 3.5. Esse processo continua até que o pacote 
chegue ao host B com o valor de VCI 4 no seu cabeçalho. Para o host B, isso identifica o pacote como 
vindo do host A. 

Em redes reais de tamanho razoável, o trabalho envolvido em configurar tabelas de VC corretamente 
em um grande número de switches rapidamente se tornaria excessivo usando os procedimentos acima. 
Assim, ou uma ferramenta de gerenciamento de rede ou algum tipo de sinalização (ou ambos) é quase 
sempre utilizado, mesmo no estabelecimento de VCs “permanentes”. No caso de PVCs, a sinalização 


Tabela 3.3 Entradas da tabela de circuitos virtuais para os switches 2 e 3 





Entradas da tabela de VCs no switch 2 











Interface de entrada VCI de saída Interface de saída VCI de saída 
3 11 2 7 

Entradas da tabela de VCs no switch 3 

Interface de entrada VCI de saída Interface de saída VCI de saída 
0 yd 1 4 





Host A 


FIGURA 3.4 Um pacote é enviado para uma rede de circuitos virtuais. 
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FIGURA 3.5 Um pacote em seu caminho por uma rede de circuitos virtuais. 


é iniciada pelo administrador da rede, enquanto os SVCs normalmente são configurados usando a 
sinalização por um dos hosts. Consideramos agora como o mesmo VC recém-descrito poderia ser 
configurado pela sinalização a partir do host. 

Para iniciar o processo de sinalização, o host A envia uma mensagem de configuração para a rede, 
ou seja, para o switch 1. A mensagem de configuração contém, entre outras coisas, o endereço de des- 
tino completo do host B. A mensagem de configuração precisa percorrer todo o caminho até B para 
criar o estado de conexão necessário em cada switch ao longo do caminho. Podemos ver que levar a 
mensagem de configuração para B é muito parecido com levar um datagrama para B, pois os switches 
precisam saber para que porta enviar a mensagem de configuração, de modo que ela por fim chegue a 
B. Por enquanto, vamos apenas assumir que os switches sabem o suficiente sobre a topologia da rede 
para descobrir como fazer isso, de modo que a mensagem de configuração passa pelos switches 2 e 3 
antes de finalmente alcançar o host B. 

Quando o switch 1 recebe a solicitação de conexão, além de enviá-la para o switch 2, ele cria uma 
nova entrada em sua tabela de circuitos virtuais para essa nova conexão. Essa entrada é exatamente 
a mesma mostrada anteriormente na Tabela 3.2. A principal diferença é que agora a tarefa de atribuir 
um valor de VCI não usado à interface é realizada pelo switch para essa porta. Neste exemplo, o switch 
escolhe o valor 5. A tabela de circuitos virtuais agora tem a seguinte informação: “Quando os pacotes 
chegarem na porta 2 com o identificador 5, envie-os pela porta 1”. Outro problema é que, de alguma 
forma, o host A precisará descobrir que deve colocar o valor de VCI 5 nos pacotes que ele deseja enviar 
para B; veremos como isso acontece mais adiante. 

Quando o switch 2 recebe a mensagem de configuração, ele realiza um processo semelhante; neste 
exemplo, ele escolhe o valor 11 como valor de VCI de chegada. De modo semelhante, o switch 3 escolhe 7 
como valor para seu VCI de chegada. Cada switch pode escolher qualquer número que desejar, desde que 
esse número não esteja atualmente em uso por alguma outra conexão na porta desse switch. Conforme 
já observamos, os VCIs possuem escopo local ao enlace; ou seja, eles não possuem significado global. 

Finalmente, a mensagem de configuração chega no host B. Supondo que B esteja funcionando e 
disposto a aceitar uma conexão do host A, ele também aloca um valor de VCI de chegada, neste caso, 4. 
Esse valor de VCI pode ser usado por B para identificar todos os pacotes provenientes do host A. 

Agora, para completar a conexão, todos precisam ser informados sobre o que seu vizinho no 
sentido direto do fluxo está usando como VCI para essa conexão. O host B envia uma confirmação 
do estabelecimento da conexão ao switch 3 e inclui nessa mensagem o VCI que escolheu (4). Agora, 
o switch 3 pode completar a entrada na tabela de circuitos virtuais para essa conexão, pois sabe que o 
valor de saída deve ser 4. O switch 3 envia a confirmação para o switch 2, especificando um VCI de 7. 
O switch 2 envia a mensagem para o switch 1, especificando um VCI de 11. Finalmente, o switch 1 passa 
a confirmação para o host A, informando que ele deve usar o VCI 5 para essa conexão. 

Nesse ponto, todos sabem tudo o que é preciso para permitir que o tráfego flua do host A ao host B. 
Cada switch tem uma entrada completa na tabela de circuitos virtuais para a conexão. Além disso, o host 
A tem uma confirmação firme de que tudo está em seu devido lugar no caminho inteiro até o host B. 
Nesse ponto, as entradas das tabelas de conexão estão prontas em todos os três switches, assim como no 
exemplo acima configurado administrativamente, mas o processo inteiro aconteceu automaticamente, 
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em resposta à mensagem de sinalização enviada por A. A fase de transferência de dados pode agora ser 
iniciada e é idêntica àquela usada no caso do PVC. 

Quando o host A não quer mais enviar dados para o host B, ele encerrar a conexão enviando uma 
mensagem de encerramento ao switch 1. O switch remove a entrada correspondente de sua tabela e 
encaminha a mensagem para os outros switches no caminho, que da mesma forma excluem as entradas 
de tabela apropriadas. Nesse ponto, se o host A tivesse que enviar um pacote com um VCI 5 ao switch 
1, ele seria descartado como se a conexão nunca tivesse existido. 

Existem várias coisas a observar sobre a comutação de circuitos virtuais: 


e Como o host A precisa esperar até que o pedido de conexão alcance o seu interlocutor no outro 
lado da rede e retorne antes de poder enviar seu primeiro pacote de dados, existe pelo menos um 
atraso de ida e volta (RTT) antes que os dados sejam enviados. 

e Embora o pedido de conexão contenha o endereço completo do host B (que pode ser bastante 
grande, por se tratar de um identificador global na rede), cada pacote de dados contém apenas 
um identificador pequeno, que é unívoco apenas em um enlace. Assim, o overhead por pacote 
causado pelo cabeçalho é reduzido em relação ao modelo de datagramas. 

e Se um switch ou um enlace em uma conexão falhar, a conexão é desfeita e uma nova precisará 
ser estabelecida. Além disso, a antiga conexão precisa ser encerrada para liberar o espaço de 
armazenamento em tabela nos switches. 

e A questão de como um switch decide para qual enlace encaminhar o pedido de conexão foi 
discutida apenas superficialmente. Basicamente, esse é o mesmo problema de montar uma tabela 
de encaminhamento para o encaminhamento de datagramas, que exige algum tipo de algoritmo 
de roteamento. O roteamento é descrito na Seção 3.3, e os algoritmos lá descritos geralmente se 
aplicam às solicitações de configuração de roteamento, além dos datagramas. 


Um dos aspectos mais interessantes dos circuitos virtuais é que, quando o host recebe a liberação 
para enviar dados, ele sabe muito a respeito da rede — por exemplo, que realmente existe uma rota até o 
receptor e que o receptor está disposto e é capaz de receber dados. Também é possível alocar recursos 
ao circuito virtual no momento em que ele é estabelecido. Por exemplo, o X.25 é uma antiga (e agora 
praticamente obsoleta) tecnologia de rede baseada em circuitos virtuais. As redes X.25 empregam a 
seguinte estratégia em três partes: 


1. Buffers são alocados a cada circuito virtual quando o circuito é inicializado. 

2. O protocolo de janela deslizante (Seção 2.5) é executado entre cada par de nós ao longo do 
circuito virtual, e esse protocolo é estendido com um mecanismo de controle de fluxo para evitar 
que o nó emissor exceda a capacidade dos buffers alocados no nó receptor. 

3. O circuito é rejeitado por determinado nó se não houver espaço suficiente disponível nos buffers 
desse nó quando a mensagem de solicitação de conexão for processada. 


Fazendo essas três coisas, cada nó tem garantias de ter os buffers de que precisa para enfileirar os 
pacotes que chegam nesse circuito. Essa estratégia básica normalmente é chamada controle de fluxo 
salto a salto. 

Em comparação, uma rede de datagramas não possui uma fase de estabelecimento de conexão, 
e cada switch processa cada pacote independentemente, tornando menos óbvio o modo como uma 
rede de datagramas alocaria recursos de um modo significativo. Em vez disso, cada pacote que chega 
compete com todos os outros pacotes pelo espaço em buffer. Se não houver espaço livre nos buffers, o 
pacote que chega precisa ser descartado. Observamos, porém, que até mesmo em uma rede baseada 
em datagramas um host de origem normalmente envia uma sequência de pacotes ao mesmo host de 
destino. Cada switch é capaz de distinguir pacotes específicos dentre o conjunto de pacotes atualmente 


“Isso não é estritamente verdadeiro. Algumas pessoas propuseram o envio “otimista” de um pacote de dados 
imediatamente após o envio do pedido de conexão. Porém, a maior parte das implementações atuais espera que 
o estabelecimento da conexão seja concluído para enviar os dados. 
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enfileirados por ele, com base no par origem/destino, e assim o switch pode garantir que os pacotes 
pertencentes a cada par origem/destino recebam uma parcela justa dos buffers do switch. Discutimos 
essa ideia com muito mais profundidade no Capítulo 6. 

No modelo de circuitos virtuais, poderíamos oferecer a cada circuito uma qualidade de serviço 
(QoS — Quality of Service) diferente. Nessa situação, o termo qualidade de serviço normalmente 
significa que a rede dá ao usuário algum tipo de garantia relacionada a desempenho, o que por sua 
vez implica que os switches reservam os recursos de que necessitam para cumprir essa garantia. Por 
exemplo, os switches ao longo de determinado circuito virtual poderiam alocar uma porcentagem da 
largura de banda de cada enlace de saída para esse circuito. Como outro exemplo, uma sequência de 
switches poderia garantir que os pacotes pertencendo a determinado circuito não sejam atrasados 
(enfileirados) por mais do que uma quantidade de tempo. Retornaremos ao assunto de qualidade de 
serviço na Seção 6.5. 


INTRODUÇÃO AO CONGESTIONAMENTO 


Um aspecto importante que os projetistas de switches enfrentam é a contenção. Tem-se uma situação 

de contenção quando vários pacotes precisam ser enfileirados em um switch porque estão disputando 

pelo mesmo enlace de saída. Veremos como os switches tratam desse problema na Seção 3.4. Você pode 
pensar na disputa como algo que acontece na escala de tempo das chegadas de pacotes individuais. O 
congestionamento, por outro lado, acontece em uma escala de tempo ligeiramente maior, quando um 
switch tem tantos pacotes enfileirados que fica sem espaço em buffer e precisa começar a descartar pacotes. 
Vamos retornar ao assunto de congestionamento no Capítulo 6, depois que tivermos visto o protocolo 

de transporte, componente da arquitetura de rede. Porém, neste ponto, observamos que o modo como 

você lida com o congestionamento está relacionado à questão de se a sua rede utiliza circuitos virtuais ou 
datagramas. 

Por um lado, suponha que cada switch aloque buffers suficientes para lidar com os pacotes 
pertencentes a cada circuito virtual que ele admite, como é feito em uma rede X.25. Nesse caso, a rede 
deixou de fora o problema do congestionamento - um switch nunca encontra uma situação em que há 
mais pacotes para enfileirar do que o espaço no buffer, pois não permite que a conexão seja estabelecida 
em primeiro lugar, a menos que possa dedicar recursos suficientes para evitar essa situação. O problema 
com essa técnica, porém, é que ela é extremamente conservadora — é improvável que todos os circuitos 
precisarão usar todos os seus buffers ao mesmo tempo, e como consequência, o switch é potencialmente 
subutilizado. 

Por outro lado, o modelo de datagrama aparentemente convida o congestionamento — você não sabe 
que existe disputa suficiente em um switch para causar congestionamento até que ele fique sem espaço 
em seus buffers. Nesse ponto, é muito tarde para impedir o congestionamento, e sua única escolha é tentar 
recuperar-se dele. A boa notícia, naturalmente, é que você pode obter uma melhor utilização dos seus 
switches, pois não está mantendo buffers em reserva para um cenário de pior caso que é muito pouco 
provável de acontecer. 

Como acontece com frequência, nada é estritamente preto no branco — existem vantagens de projeto 
em rejeitar a possibilidade de congestionamento (como o modelo X.25 faz) e em não fazer nada sobre o 
congestionamento até que ele aconteça (como o modelo de datagramas simples faz). Há também pontos 
intermediários entre esses dois extremos. Descrevemos alguns desses pontos de projeto no Capítulo 6. 





Houve uma série de exemplos bem sucedidos de tecnologias de circuito virtual com o passar dos 
anos, principalmente X.25, Frame Relay e Asynchronous Transfer Mode (ATM — Modo de Transferência 
Assíncrona). Entretanto, com o sucesso do modelo sem conexão da Internet, nenhum deles tem uma 
grande popularidade hoje. Uma das aplicações mais comuns dos circuitos virtuais por muitos anos 
foi a construção de redes privadas virtuais (VPNs -Virtual Private Networks), um assunto discutido na 
Seção 3.2.9. Atualmente, até mesmo essa aplicação é suportada principalmente usando tecnologias 
baseadas na Internet. 
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COMUTAÇÃO ÓPTICA 


Para um observador casual da indústria de redes em torno do ano 2000, podia parecer que o tipo mais 
interessante de comutação era a comutação óptica. Na verdade, a comutação óptica tornou-se uma 
tecnologia importante no final da década de 1990, devido a uma confluência de vários fatores. Um fator 

foi a disponibilidade comercial de equipamentos de Multiplexação por Divisão de Comprimento de Onda 
Densa (DWDM - Dense Wavelength Division Multiplexing), que permite enviar muitas informações por uma 
única fibra, transmitindo em um grande número de comprimentos de onda ópticos (ou cores) ao mesmo 
tempo. Assim, por exemplo, pode-se enviar dados em 100 ou mais comprimentos de onda diferentes, e cada 
comprimento de onda pode transportar até 10 Gbps de dados. 

Um segundo fator foi a disponibilidade comercial dos amplificadores ópticos. Os sinais ópticos são 
atenuados à medida que passam pela fibra, e após alguma distância (cerca de 40 km ou mais) sua potência 
precisa ser regenerada de alguma maneira. Antes dos amplificadores ópticos, era preciso colocar repetidores 
no caminho para recuperar o sinal óptico, convertê-lo em um sinal elétrico digital e depois convertê-lo de 
volta em um sinal óptico novamente. Antes que você pudesse entregar os dados para um repetidor, teria 
que demultiplexá-los usando um terminal DWDM. Assim, um grande número de terminais DWDM seria 
necessário somente para controlar um único par de fibras por uma longa distância. Os amplificadores 
ópticos, diferentemente dos repetidores, são dispositivos analógicos que amplificam qualquer sinal enviado 
pela fibra, mesmo que ele seja enviado usando uma centena de comprimentos de onda diferentes. Os 
amplificadores ópticos, portanto, tornaram o mecanismo de DWDM muito mais atraente, pois agora um par 
de terminais DWDM poderiam falar um com o outro quando separados por uma distância de centenas de 
quilômetros. Além disso, você poderia até mesmo atualizar os equipamentos de DWDM nos terminais sem 
tocar nos amplificadores ópticos no meio do caminho, pois eles amplificarão 100 comprimentos de onda tão 
facilmente quanto 50. 

Com DWDM e amplificadores ópticos, foi possível montar redes ópticas com uma capacidade imensa. 
Mas pelo menos mais um tipo de dispositivo é necessário para que essas redes se tornem úteis — o switch 
óptico. A maioria dos chamados switches ópticos de hoje na realidade realizam sua função de comutação 
eletronicamente e, de um ponto de vista arquitetônico, eles têm mais coisas em comum com os comutadores 
de circuitos da rede telefônica do que com os comutadores de pacotes descritos neste capítulo. Um 
switch óptico típico tem um grande número de interfaces que entendem os quadros SONET e é capaz de 
interconectar um canal SONET de uma interface de entrada com uma interface de saída. Assim, com um 
switch óptico, é possível oferecer canais SONET do ponto A para o ponto B por meio do ponto C mesmo que 
não haja um caminho de fibra direto de A para B — só é preciso haver um caminho de A para C, um switch 
em C e um caminho de C para B. Neste sentido, um switch óptico tem alguma relação com os switches da 
Figura 3.3, pois ele cria a ilusão de uma conexão entre dois pontos mesmo quando não existe uma conexão 
física direta entre eles. Porém, os switches ópticos não oferecem circuitos virtuais; eles oferecem circuitos 
“reais” (por exemplo, um canal SONET). Existem até mesmo alguns tipos mais novos de switches ópticos que 
usam espelhos microscópicos, eletronicamente controlados, para refletir toda a luz de uma porta do switch 
para outra, de modo que pode haver um canal óptico ininterrupto do ponto A até o ponto B. A tecnologia por 
trás desses dispositivos é chamada sistemas microeletromecânicos (MEMS — Microelectromechanical Systems). 

Não explicamos as redes ópticas com profundidade neste livro, em parte por razões de espaço. Para 
muitas finalidades práticas, você pode pensar nas redes ópticas como uma parte da infraestrutura que 
permite que as companhias telefônicas forneçam enlaces SONET ou outros tipos de circuitos onde e quando 
você precisar deles. Porém, vale a pena observar que muitas das tecnologias discutidas mais adiante neste 
livro, como protocolos de roteamento e comutação de rótulos multiprotocolo, possuem aplicação no mundo 
das redes ópticas. 





Asynchronous Transfer Mode (ATM) 

O Modo de Transferência Assíncrona (ATM -Asynchronous Transfer Mode) é possivelmente a tecnologia 
de rede baseada em circuitos virtuais mais conhecida, embora agora já tenha passado seu período 
de auge em termos de implantação. O ATM tornou-se uma tecnologia importante na década de 1980 
e início da década de 1990 por diversos motivos, sendo não menos importante o fato de que ele foi 
abraçado pela indústria telefônica, que historicamente tinha sido pouco ativa em comunicações de 
dados (além de como fornecedor de enlaces a partir dos quais outras pessoas montavam redes). O ATM 
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FIGURA 3.6 Formato de célula ATM no UNI. 


também estava no lugar certo na hora certa, como uma tecnologia de comutação de alta velocidade 
que apareceu em cena exatamente quando meios compartilhados, como Ethernet e token rings, esta- 
vam começando a ficar muito lentos para os usuários de redes de computadores. De certa maneira, o 
ATM foi uma tecnologia concorrente à comutação Ethernet, e foi vista por muitos também como um 
concorrente do IP. 

Existem alguns aspectos do ATM que precisam ser examinados. A figura do formato de um pacote 
ATM - normalmente chamado de célula ATM - na Figura 3.6 será usada para ilustrar os principais 
pontos. Vamos ignorar os bits de controle de fluxo genérico (GFC — Generic Flow Control), que nunca 
tiveram muito uso, e começar com os 24 bits que são rotulados como VPI (Virtual Path Identifier ou 
Identificador de Caminho Virtual — 8 bits) e VCI (Virtual Circuit Identifier ou Identificador de Circuito 
— 16 bits). Se você considerar esses bits juntos, como um único campo de 24 bits, eles correspondem ao 
identificador de circuito virtual introduzido anteriormente. O motivo para quebrar o campo em duas 
partes foi permitir um nível de hierarquia: todos os circuitos com o mesmo VPI podiam, em alguns 
casos, ser tratados como um grupo (um caminho virtual) e todos poderiam ser comutados examinando 
apenas o VPI, simplificando o trabalho de um switch ao poder ignorar todos os bits do VCI e reduzindo 
consideravelmente o tamanho da tabela de VCs. 

Indo para o último byte de cabeçalho, encontramos uma verificação de redundância cíclica (CRC) de 
8 bits, conhecida como verificação de erro do cabeçalho (HEC — Header Error Check). Ela usa o polinômio 
CRC-8 descrito na Seção 2.4.3 e oferece capacidade de detecção de erros e correção de erros de único 
bit apenas para o cabeçalho da célula. Proteger o cabeçalho da célula é particularmente importante 
porque um erro no VCI fará com que a célula seja encaminhada erroneamente. 

Provavelmente, a coisa mais significativa a se observar sobre a célula ATM, e o motivo para ela ser 
chamada de célula e não de pacote, é que ela vem com apenas um tamanho: 53 bytes. Qual foi o motivo 
para isso? Um grande motivo foi facilitar a implementação de switches em hardware. Quando o ATM 
estava sendo criado em meados e final da década de 1980, a Ethernet de 10 Mbps era a tecnologia de 
ponta em termos de velocidade. Para conseguir muito mais velocidade, a maioria das pessoas pensava 
em termos de hardware. Além disso, no mundo da telefonia, as pessoas pensam grande quando pensam 
em switches — switches de telefone normalmente atendem a milhares de clientes. Os pacotes de tamanho 
fixo passaram a ser uma coisa muito útil se você quisesse montar switches rápidos, altamente escaláveis. 
Existem dois motivos principais para isso: 


1. É mais fácil construir hardware para realizar tarefas simples, e o trabalho de processar pacotes é 
mais simples quando você já sabe o tamanho que cada um terá. 

2. Se todos os pacotes tiverem o mesmo tamanho, então você poderá ter muitos elementos de 
comutação, todos fazendo a mesma coisa em paralelo, cada um deles levando o mesmo tempo 
para realizar seu trabalho. 


Esse segundo motivo, permitir o paralelismo, melhora bastante a escalabilidade da arquitetura de 
switches. Seria um exagero dizer que os switches com hardware paralelo só podem ser construídos 
usando células de tamanho fixo. Porém, certamente é verdade que as células facilitam a tarefa de cons- 
truir esse tipo de hardware e que havia muito conhecimento disponível sobre como construir switches 
de células em hardware na época em que os padrões ATM estavam sendo definidos. Na realidade, esse 
mesmo princípio ainda é aplicado em muitos switches e roteadores de hoje, mesmo que eles tratem 
pacotes de tamanho variável — eles cortam esses pacotes em algum tipo de célula a fim de comutá-los, 
conforme veremos na Seção 3.4. 

Tendo decidido usar pacotes pequenos e de tamanho fixo, a próxima pergunta é: Qual é o tamanho 
correto no qual fixá-los? Se você adotar células muito pequenas, então a quantidade de informação de 
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cabeçalho que precisa ser transportada fica muito maior quando comparada à quantidade de dados que 
cabem em uma célula, de modo que a porcentagem da largura de banda do enlace que é de fato usada 
para transportar dados é reduzida. Ainda mais sério do que isso, se você construir um dispositivo que 
processa células a uma velocidade máxima de algum número de células por segundo, então, à medida 
que as células ficam menores, a taxa de dados total cai de forma diretamente proporcional ao tama- 
nho da célula. Um exemplo desse tipo de dispositivo poderia ser um adaptador de rede que remonta 
células em unidades maiores antes de entregá-las ao host. O desempenho desse dispositivo depende 
diretamente do tamanho da célula. Por outro lado, se você adotar células muito grandes, então existe um 
problema de largura de banda desperdiçada devido à necessidade de adicionar dados de enchimento 
(padding) aos dados transmitidos para obter uma célula completa. Se o payload (ou carga útil) da célula 
tiver 48 bytes e você quiser enviar 1 byte, você precisará enviar 47 bytes de preenchimento. Se isso 
acontece com frequência, então a utilização do enlace será muito baixa. A combinação de uma razão 
relativamente alta entre tamanho de cabeçalho e de payload juntamente com a frequência de envio de 
células parcialmente preenchidas de fato levou a alguma ineficiência observável nas redes ATM, que 
alguns detratores chamaram de imposto das células. 

Acontece que 48 bytes foi um tamanho escolhido para o payload da célula ATM como um meio-termo. 
Houve bons argumentos para células maiores e menores, mas 48 não deixou quase ninguém satisfeito -uma 
potência de dois certamente teria sido melhor para os computadores trabalharem. 


3.1.3 Roteamento na origem 


Uma terceira técnica de comutação que não usa circuitos virtuais nem datagramas convencionais é co- 
nhecida como roteamento na origem. O nome deriva do fato de que toda a informação sobre a topologia 
da rede que é necessária para comutar um pacote pela rede é fornecida pelo host de origem. 

Existem várias maneiras de implementar o roteamento na origem. Uma seria atribuir um número 
a cada saída de cada switch e colocar esse número no cabeçalho do pacote. A função de comutação é 
então muito simples: para cada pacote que chegasse em uma entrada, o switch leria o número de porta 
no cabeçalho e transmitiria o pacote nessa saída. Porém, como geralmente haverá mais de um switch 
no caminho entre o host emissor e o receptor, o cabeçalho para o pacote precisa conter informações 
suficientes para permitir que cada switch no caminho determine em qual saída o pacote precisa ser 
colocado. Um modo de fazer isso seria colocar uma lista ordenada de portas de switch no cabeçalho e 
rotacionar a lista de modo que o próximo switch no caminho sempre esteja na frente da lista. A Figura 3.7 
ilustra essa ideia. 


Switch 1 





| p Switch2 


Em À 











FIGURA 3.7 Roteamento na origem em uma rede comutada (onde o switch lê o número mais à direita). 
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ELSEVIER 


ONDE ESTÃO ELES AGORA? 


ATM 

Houve um período de tempo no final da década de 1980 e início da década de 1990 quando o ATM parecia 
(para muitas pessoas) pronto para dominar o mundo. As principais companhias de telecomunicação 
ofereciam suporte a esta tecnologia e a promessa de redes de alta velocidade, que poderiam integrar 
facilmente voz, vídeo e dados em uma rede comum parecia atraente. Os proponentes do ATM chamavam 
tudo que usasse pacotes de tamanho variável - tecnologias como Ethernet e IP — de tecnologias “legadas”. 
Hoje, porém, Ethernet e IP dominam, e ATM é visto como uma tecnologia do passado. Você ainda poderá 
encontrar bolsões de implantação do ATM, principalmente como um meio de obter acesso a redes IP 
Especificamente, muitas redes de acesso DSL (Digital Subscriber Line) foram montadas usando ATM, de 
modo que parte dos acessos à Internet de banda larga hoje é, na realidade, feito por enlaces ATM, embora 
esse fato esteja completamente ocultado pelos modems DSL, que recebem quadros Ethernet e os dividem 
em células que são posteriormente remontadas dentro da rede de acesso. 

Há espaço para debate quanto ao motivo pelo qual ATM não dominou o mundo. Uma coisa que parece 
fundamentalmente importante em retrospecto foi que o IP estava indo bem em seu caminho para se 
tornar completamente estabelecido quando o ATM apareceu. Embora a Internet não estivesse no radar de 
muitas pessoas na década de 1980, ela já estava adquirindo alcance global e o número de hosts conectados 
estava dobrando a cada ano. Além disso, como a finalidade inteira do IP era interconectar facilmente todos 
os diferentes tipos de redes, quando o ATM apareceu, ao invés de substituir o IP como seus proponentes 
imaginavam que poderia, o ATM foi rapidamente absorvido como apenas outro tipo de rede sobre a qual 
o IP poderia ser utilizado. Nesse ponto, ATM estava mais diretamente em concorrência com o Ethernet do 
que com IP e o aparecimento de switches Ethernet pouco dispendiosos e da Ethernet de 100 Mbps sem 
mecanismos ópticos dispendiosos garantiu que o padrão Ethernet continuasse estabelecido como uma 
tecnologia de área local. 





Neste exemplo, o pacote precisa atravessar três switches para ir do host A ao host B. No switch 1, ele 
precisa sair na porta 1, no próximo switch ele precisa sair na porta 0, eno terceiro switch ele precisa sair 
na porta 3. Assim, o cabeçalho original quando o pacote sai do host A contém a lista de portas (3, 0, 1), 
onde consideramos que cada switch lê o elemento mais à direita da lista. Para garantir que o próximo 
switch receba a informação apropriada, cada switch rotaciona a lista após ter lido sua própria entrada. 
Assim, o cabeçalho do pacote quando sai do switch 1 a caminho do switch 2 agora é (1,3, 0); o switch 2 
realiza outra rotação e envia um pacote com (0, 1,3) no cabeçalho. Embora não seja mostrado, o switch 
3 realiza outra rotação, restaurando o cabeçalho ao que era quando o host À o enviou. 

Existem vários pontos a observar sobre essa técnica. Primeiro, ela considera que o host A sabe o 
suficiente sobre a topologia da rede para construir um cabeçalho contendo todas as direções corretas 
para cada switch no caminho. Isso é semelhante ao problema de montar as tabelas de encaminhamento 
em uma rede de datagramas ou descobrir para onde enviar um pacote de configuração em uma rede 
de circuitos virtuais. Segundo, observe que não podemos prever o tamanho que o cabeçalho precisa 
ter, pois ele deve ser capaz de carregar uma palavra de informação para cada switch no caminho. Isso 
significa que os cabeçalhos provavelmente possuem tamanho variável sem um limite máximo, a menos 
que possamos prever com absoluta certeza o número máximo de switches por meio dos quais um pacote 
precisará passar. Terceiro, existem algumas variações nessa técnica. Por exemplo, em vez de rotacionar o 
cabeçalho, cada switch poderia simplesmente remover o primeiro elemento enquanto o utiliza. Porém, 
a rotação tem uma vantagem em relação à remoção: o host B recebe uma cópia do cabeçalho completo, 
que poderá ajudá-lo a descobrir como enviar uma resposta ao host A. Outra alternativa é fazer com 
que o cabeçalho transporte um ponteiro para a entrada atual da “próxima porta”, de modo que cada 
switch simplesmente atualize o ponteiro em vez de girar o cabeçalho; isso pode ser mais eficiente de 
se implementar. Mostramos essas três técnicas na Figura 3.8. Em cada caso, a entrada que esse switch 
precisa ler é A, e a entrada que o próximo switch precisa ler é B. 

O roteamento na origem pode ser usado tanto em redes de datagrama como em redes de circuitos 
virtuais. Por exemplo, o IP que é um protocolo de datagramas, inclui uma opção de roteamento na 
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A FIGURA 3.8 Três maneiras de tratar os cabeçalhos 
Cabeçalho entrando no roteamento na origem: (a) rotação; (b) remoção; 
no switch DIC|BJA D/C|BJA PrjD|C|BJA (c) ponteiro. Os rótulos são lidos da direita para 
a esquerda. 


CN 


A|D|CI|B D|C|B Pr DCBA 
(a) (b) (c) 


Cabeçalho saindo 
do switch 


origem que permite que pacotes selecionados sejam roteados na origem, enquanto a maioria deles seja 
comutada como datagramas convencionais. O roteamento na origem também é usado em algumas 
redes de circuitos virtuais como um meio de trasmitir a solicitação de configuração inicial ao longo do 
caminho da origem até o destino. 

As rotas de origem às vezes são classificadas como “estritas” ou “livres”. Em uma rota de origem es- 
trita, cada nó ao longo do caminho precisa ser especificado, enquanto uma rota de origem livre apenas 
especifica um conjunto de nós a serem visitados, sem dizer exatamente como passar de um nó para o 
seguinte. Uma rota de origem livre pode ser imaginada como um conjunto de pontos de sinalização, 
em vez de uma rota completamente especificada. A opção de rota livre pode ser útil para limitar a 
quantidade de informação que uma origem precisa obter para criar uma rota de origem. Em qualquer 
rede razoavelmente grande, é provável que seja difícil para um host obter a informação de caminho 
completa de que precisa para construir uma rota de origem estrita correta para qualquer destino. Mas 
os dois tipos de rotas de origem encontram aplicação em certos cenários, um dos quais é descrito na 
Seção 4.3. 


3.1.4 Bridges e switches de LAN A 


VLAN 
Tendo discutido algumas das ideias básicas por trás da comutação, agora vamos focalizar mais de perto 
algumas tecnologias de comutação específicas. Começamos considerando uma classe de switch que é 
usada para encaminhar pacotes entre LANs (redes locais), como as redes Ethernet. Esses switches às vezes 
são conhecidos como bridges (pontes), e são muito utilizados em redes de universidades e empresas. 

Suponha que você tenha um par de redes Ethernet que queira interconectar. Uma abordagem que 
você poderia tentar é colocar um repetidor entre elas, conforme descrevemos no Capítulo 2. Porém, essa 
solução não funcionaria se a rede resultante excedesse as limitações físicas do padrão Ethernet. (Lembre 
que são permitidos apenas dois repetidores entre qualquer par de hosts e não mais do que um total de 
2.500 m de comprimento.) Uma alternativa seria colocar um nó com um par de adaptadores Ethernet 
entre as duas redes Ethernet e fazer com que o nó encaminhe pacotes de uma rede para outra. Esse nó 
seria diferente de um repetidor, o qual opera sobre bits e não sobre quadros, e apenas copia cegamente 
os bits recebidos em uma interface para outra. Em vez disso, esse nó implementaria totalmente os 
protocolos de detecção de colisão e de acesso ao meio do Ethernet em cada interface. Logo, as res- 
trições de extensão e número de hosts do Ethernet, que se referem ao gerenciamento de colisões, não 
se aplicariam ao par combinado de redes Ethernet conectadas dessa maneira. Esse dispositivo opera 
no modo promíscuo, aceitando todos os quadros transmitidos em qualquer uma das redes Ethernet e 
encaminhando-os para a outra. 

O nó que acabamos de descrever normalmente é chamado de bridge (ponte), e uma coleção de LANs 
conectadas por uma ou mais bridges normalmente forma uma LAN estendida, como é chamada. Em 
suas variantes mais simples, as bridges simplesmente aceitam quadros da LAN em suas entradas e os 
encaminham para todas as outras saídas. Essa estratégia simples foi usadas pelas primeiras bridges, 
mas tem algumas limitações bastante sérias, como veremos mais adiante. Diversas melhorias foram 
acrescentadas com o passar dos anos para transformar as bridges em um mecanismo eficaz para in- 
terconectar um conjunto de LANS. O restante desta seção contém os detalhes mais interessantes. 

Observe que uma bridge corresponde a nossa definição de um switch da seção anterior: um dis- 
positivo de múltiplas entradas e múltiplas saídas, que transfere pacotes de uma entrada para uma ou 
mais saídas. E lembre que isso oferece uma forma de aumentar a largura de banda total de uma rede. 
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Por exemplo, embora um único segmento Ethernet possa transportar somente 100 Mbps de tráfego 

total, uma bridge Ethernet pode transportar até 100n Mbps, onde n é o número de portas (entradas e 

saídas) na bridge. 


Bridges com aprendizado 

A primeira otimização que podemos fazer em uma bridge é observar que ela não precisa encaminhar 
todos os quadros que recebe. Considere a bridge na Figura 3.9. Sempre que um quadro do host A que é 
endereçado para o host B chega na porta 1, não é preciso que a bridge encaminhe o quadro pela porta 
2. A questão, portanto, é saber como uma bridge descobre em que porta os diversos hosts residem. 

Uma opção seria fazer com que um operador humano carregasse uma tabela na bridge, semelhante 
aquela mostrada na Tabela 3.4. Depois disso, sempre que a bridge receber um quadro na porta 1 que 
seja endereçado ao host A, ela não encaminharia o quadro para a porta 2; isso não seria preciso porque 
o host A já teria recebido diretamente o quadro na LAN conectada na porta 1. Sempre que um quadro 
endereçado ao host A fosse recebido na porta 2, a bridge encaminharia o quadro pela porta 1. 

Ninguém realmente constrói bridges em que a tabela é configurada a mão. Ter um humano mantendo 
essa tabela é muito trabalhoso, e existe um truque simples pelo qual uma bridge pode aprender essa 
informação por si mesma. A ideia é que cada bridge inspecione o endereço de origem em todos os qua- 
dros que recebe. Assim, quando o host A envia um quadro para um host em qualquer lado da bridge, a 
bridge recebe esse quadro e registra o fato de que um quadro do host A acabou de ser recebido na porta 
1. Desse modo, a bridge pode montar uma tabela exatamente como a Tabela 3.4. 

Observe que uma bridge usando essa tabela implementa uma versão do modelo de encaminhamento 
de datagramas (ou sem conexão) descrito na Seção 3.1.1. Cada pacote carrega um endereço global, e a 
bridge decide para qual saída enviar um pacote examinando esse endereço em uma tabela. 

Quando uma bridge é inicializada pela primeira vez, essa tabela está vazia; as entradas são acres- 
centadas com o tempo. Além disso, um tempo de expiração é associado a cada entrada, e a bridge des- 
carta a entrada após um período de tempo especificado. Isso é feito para proteger contra a situação em 
que um host — e, por conseguinte, seu endereço de LAN - é movido de uma rede para outra. Assim, essa 
tabela não é necessariamente completa. Se a bridge receber um quadro endereçado para um host que 
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X Y Z FIGURA 3.9 Ilustração de uma bridge com aprendizado. 


Tabela 3.4 Tabela de encaminhamento mantida por uma bridge 
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atualmente não esteja na tabela, ela vai em frente e encaminha o quadro por todas as outras portas. 
Em outras palavras, essa tabela é simplesmente uma otimização que filtra alguns quadros; ela não é 
necessária para que o equipamento opere corretamente. 


Implementação 

O código que implementa o algoritmo de bridge com aprendizado é muito simples, e vamos esboçá-lo 
aqui. A estrutura BridgeEntry especifica uma única entrada na tabela de encaminhamento da bridge; 
estas são armazenadas em uma estrutura do tipo Map (que admite as operações mapCreate, mapBind 
e mapResolve) para permitir que entradas sejam localizadas de modo eficiente quando os pacotes 
chegarem de origens já presentes na tabela. A constante MAX TTL especifica por quanto tempo uma 
entrada é mantida na tabela antes de ser descartada. 


tabela de bridge */ 

fdefine MAX TTL 120 /* tempo (em segundos) antes 
que uma entrada seja removida */ 

typedef struct ( 


MacAddr destination; /* Endereço MAC de um nó */ 

int ifnumber; /* interface para alcançá-lo */ 

u short TTL; /* tempo de vida */ 

Binding binding; /* vínculo na estrutura de Map */ 
} BridgeEntry; 
int numEntries = 0; 


Map bridgeMap = mapCreate (BRIDGE TAB SIZE, 


Arotina que atualiza a tabela de encaminhamento quando um novo pacote chega é dada por updateTable. 
Os argumentos passados são o endereço MAC (Media Access Control) da origem, contido no pacote, e o 
número da interface na qual ele foi recebido. Outra rotina, que não é mostrada aqui, é chamada em intervalos 
regulares, percorre as entradas na tabela de encaminhamento e decrementa o campo de TTL (tempo de vida) 
de cada entrada, descartando quaisquer entradas cujo TTL tenha atingido 0. Observe que o TTL é reiniciado 
em MAX TTL toda vez que um pacote chega para atualizar a entrada existente na tabela, e que a interface 
na qual o destino pode ser alcançado é atualizada para refletir o pacote recebido mais recentemente. 


updateTable (MacAddr src, int inif) 


{ 




















B 

i &src, (void **)&b) == FALSE ) 

i 

/* este endereço não está na tabela, então tenta incluí-lo*/ 
if (numEntries < BRIDGE_TAB_SIZE) 

{ 

b = NEW (BridgeEntry); 

b->binding = mapBind( bridgeMap, &src, b); 

/* usa end. de origem do pacote como end. de destino na tabela */ 
b- -ination = src; 

numEntries++; 

} 

else 

{ 

/* não há espaço para incluir end. na tabela agora, portanto desiste*/ 
return; 

} 

) 

/* reinicia TTL e usa interface de entrada mais recente */ 
b->TTL = MAX TTL; 

b->ifnumber = inif; 


Observe que essa implementação adota uma estratégia simples no caso em que a tabela da bridge 
atinge sua capacidade máxima — ela simplesmente deixa de incluir o novo endereço. Lembre que a 
completude da tabela da bridge não é necessária para que o encaminhamento seja feito corretamente; 
isso apenas otimiza o desempenho. Se houver alguma entrada na tabela que não esteja atualmente 
sendo usada, ela eventualmente atingirá o tempo limite e será removida, criando espaço para uma 
nova entrada. Uma técnica alternativa seria chamar algum tipo de algoritmo de substituição de cache 
ao encontrar a tabela cheia; por exemplo, poderíamos localizar e remover a entrada com o menor TTL 
para acomodar a nova entrada. 
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Algoritmo de Spanning Tree 

A estratégia anterior funciona muito bem até que a LAN estendida apresente um ciclo, caso em que ele 
falhará de uma forma horrível - os quadros potencialmente ficam percorrendo em círculos a LAN es- 
tendida indefinidamente. Isso é fácil de ver no exemplo representado na Figura 3.10, em que, por exemplo, 
as bridges B1, B4 e B6 formam um ciclo. Suponha que um pacote entre na bridge B4 a partir da Ethernet J 
e que o endereço de destino não esteja na tabela de encaminhamento da bridge: B4 envia uma cópia do 
pacote pelas redes Ethernet H e I. Agora, a bridge B6 encaminha o pacote para a rede Ethernet G, onde 
B1 o veria e o encaminharia de volta à rede Ethernet H; B4 ainda não tem esse destino em sua tabela, de 
modo que ele encaminha o pacote de volta às redes Ethernet I e J. Não há nada que impeça que esse ciclo 
se repita indefinidamente, com os pacotes percorrendo as duas direções entre B1, B4 e B6. 

Por que uma LAN estendida passaria a ter um ciclo? Uma possibilidade é que a rede é gerenciada por 
mais de um administrador, por exemplo, pois se espalha por vários departamentos em uma organização. 
Nesse ambiente, é possível que nenhuma pessoa saiba a configuração inteira da rede, significando que 
uma bridge que fecha um ciclo poderia ser acrescentada sem que mais ninguém saiba. Um segundo 
cenário, mais provável, é que os ciclos são propositalmente criados na rede com uma finalidade: fornecer 
redundância em caso de falha. Afinal, uma rede sem ciclos só precisa de uma falha no enlace para ficar 
dividida em duas partições isoladas uma da outra. 

Qualquer que seja a causa, as bridges precisam ser capazes de tratar dos ciclos de forma adequada. O 
problema é resolvido fazendo com que as bridges executem um algoritmo de spanning tree distribuído. 
Se você pensar na LAN estendida como sendo representada por um grafo que possivelmente possui 
ciclos, então uma spanning tree é um subgrafo desse grafo, que abrange (se espalha — span) por todos os 
vértices, mas não contém ciclos. Ou seja, uma spanning tree mantém todos os vértices do grafo original, 
mas remove algumas das arestas. Por exemplo, a Figura 3.11 mostra um grafo cíclico à esquerda e uma 
de possivelmente muitas spanning trees à direita. 


FIGURA 3.10 LAN estendida com loops. 


FIGURA 3.11 Exemplo de (a) um grafo cíclico; 
(b) uma spanning tree correspondente. 
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A ideia de uma spanning tree é muito simples: ela é um subconjunto da topologia de rede real que 
não possui ciclos e que alcança todas as LANs na LAN estendida. A parte difícil é como todas as bridges 
coordenam suas decisões para chegar a uma única visão da spanning tree. Afinal, uma topologia nor- 
malmente é capaz de ser coberta por várias spanning trees. A resposta está no protocolo de spanning 
tree, que descrevemos a seguir. 

O algoritmo de spanning tree, que foi desenvolvido por Radia Perlman da Digital Equipment 
Corporation, é um protocolo usado por um conjunto de bridges para chegar a uma acordo sobre 
uma spanning tree para uma determinada LAN estendida. (A especificação IEEE 802.1 para bridges 
de LAN é baseada nesse algoritmo.) Na prática, isso significa que cada bridge decide a respeito das 
portas pelas quais ela está disposta e não está disposta a encaminhar quadros. De certa forma, é por 
meio da remoção de portas da topologia que a LAN estendida é reduzida a uma árvore acíclica.! É até 
mesmo possível que uma bridge inteira não participe do encaminhamento de quadros, o que parece 
estranho à primeira vista. Contudo, o algoritmo é dinâmico, significando que as bridges sempre estão 
preparadas para se reconfigurarem em uma nova spanning tree caso alguma bridge falhe e, portanto, 
essas portas e bridges não usadas oferecem a capacidade redundante necessária para se recuperar 
de falhas. 

A ideia principal da spanning tree é que as bridges selecionam as portas pelas quais encaminharão 
quadros. O algoritmo seleciona portas da seguinte forma. Cada bridge tem um identificador exclusivo; 
para os nossos propósitos, usamos os rótulos B1, B2, B3 e assim por diante. O algoritmo primeiro 
elege a bridge com o menor ID como raiz da spanning tree; o modo exato como essa eleição acontece 
é descrito a seguir. A bridge raiz sempre encaminha quadros por todas as suas portas. Em seguida, 
cada bridge calcula o caminho mais curto até a raiz e anota qual de suas portas está nesse caminho. 
Essa porta também é selecionada como caminho preferido da bridge para a raiz. Finalmente, todas 
as bridges conectadas a uma determinada LAN elegem uma única bridge designada, que será res- 
ponsável por encaminhar os quadros para a bridge raiz. A bridge designada de cada LAN será aquela 
que estiver mais próxima da raiz. Se duas ou mais bridges estiverem à mesma distância da raiz, então 
os identificadores das bridges serão usados para desempate, e o menor ID vence. Naturalmente, 
cada bridge está conectada a mais de uma LAN, de modo que ela participa na eleição de uma bridge 
designada para cada LAN à qual está conectada. Com efeito, isso significa que cada bridge decide se 
ela é a bridge designada em relação a cada uma de suas portas. A bridge encaminha quadros pelas 
portas para as quais ela é a bridge designada. 

A Figura 3.12 mostra a spanning tree que corresponde à LAN estendida mostrada na Figura 3.10. Neste 
exemplo, B1 é a bridge raiz, pois tem o menor ID. Observe que tanto B3 quanto B5 estão conectados 
à LAN A, mas B5 é a bridge designada, pois está mais próxima da raiz. De modo semelhante, tanto B5 
quanto B7 estão conectados à LAN B, mas neste caso B5 é a bridge designada, pois tem o menor ID; 
ambos estão a uma mesma distância de B1. 

Embora seja possível que um humano examine a LAN estendida mostrada na Figura 3.10 e calcule 
a spanning tree dada na Figura 3.12 de acordo com as regras dadas anteriormente, as bridges em 
uma LAN estendida não têm o luxo de serem capazes de ver a topologia da rede inteira, muito menos 
examinar outras bridges para determinar seus IDs. Em vez disso, as bridges precisam trocar mensagens 
de configuração umas com as outras e depois decidir se elas são ou não a raiz de uma bridge designada 
com base nessas mensagens. 

Especificamente, as mensagens de configuração contêm três informações: 


1. O ID para a bridge que está enviando a mensagem. 
2. O ID para aquela que a bridge emissora acredita ser a bridge raiz. 
3. A distância, medida em hops, da bridge emissora à bridge raiz. 


“Representar uma LAN estendida como um grafo abstrato de certa forma é estranho. Basicamente, você faz com que as 
bridges e as LANs correspondam aos vértices do grafo e as portas correspondam às arestas do grafo. Porém, a spanning tree 
que iremos calcular para esse grafo precisa se espalhar somente pelos nós que correspondem a redes. É possível que os nós 
que correspondem a bridges sejam desconectados do restante do grafo. Isso corresponde a uma situação em que todas as 
portas conectando uma bridge a diversas redes são removidas pelo algoritmo. 
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A FIGURA 3.12 Spanning tree com algumas portas não 
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Cada bridge registra a melhor mensagem de configuração que viu em cada uma de suas portas (“me- 
lhor” é definido a seguir), incluindo tanto mensagens que recebeu das outras bridges quanto mensagens 
que ela mesma transmitiu. 

Inicialmente, cada bridge pensa que é a raiz e, portanto, envia uma mensagem de configuração 
por cada uma de suas portas, identificando-se como a raiz e informando uma distância O até a raiz. Ao 
receber uma mensagem de configuração por uma porta em particular, a bridge verifica se essa nova 
mensagem é melhor do que a melhor configuração atual registrada para essa porta. A nova mensagem 
de configuração é considerada melhor do que a informação atualmente registrada se qualquer uma das 
seguintes condições for verdadeira: 


e Ela identifica uma raiz com um ID menor. 
e Ela identifica uma raiz com um ID igual mas com uma distância mais curta. 
e OID daraiz e a distância são iguais, mas a bridge emissora tem um ID menor. 


Se a nova mensagem for melhor do que a informação atualmente registrada, a bridge descarta a 
informação antiga e salva a nova informação. Porém, ela primeiro soma 1 ao campo de distância até 
a raiz, pois a bridge está um salto mais distante da raiz do que a bridge que enviou a mensagem. 

Quando uma bridge recebe uma mensagem de configuração indicando que ela não é a bridge raiz 
— ou seja, uma mensagem de uma bridge com um ID menor -, a bridge para de gerar mensagens de 
configuração por conta própria e, em vez disso, apenas encaminha mensagens de configuração de outras 
bridges, depois de primeiro somar 1 ao campo de distância. De modo semelhante, quando uma bridge 
recebe uma mensagem de configuração que indica que ela não é a bridge designada para essa porta - ou 
seja, uma mensagem de uma bridge que está mais próxima da raiz ou igualmente distante da raiz mas 
com um ID menor -, a bridge para de enviar mensagens de configuração por essa porta. Assim, quando 
o sistema se estabiliza, somente a bridge raiz ainda estará gerando mensagens de configuração, e as 
outras bridges estão encaminhando essas mensagens apenas por portas para as quais elas são a bridge 
designada. Nesse ponto, uma spanning tree foi montada e todas as bridges estão de acordo sobre quais 
portas estão em uso para a spanning tree. Somente essas portas podem ser usadas para encaminhar 
pacotes de dados na LAN estendida. 

Vejamos como isso funciona com um exemplo. Considere o que aconteceria na Figura 3.12 se a energia 
tivesse sido restaurada ao prédio que contém essa rede, de modo que todas as bridges são inicializadas 
ao mesmo tempo. Todas as bridges começariam afirmando ser a raiz. Indicamos uma mensagem de 
configuração do nó X em que afirma estar a uma distância d do nó raiz Y como (Y, d, X). Concentrando-se 
na atividade no nó B3, uma sequência de eventos se desdobraria conforme se segue: 
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B3 recebe (B2, 0, B2). 

Como 2 <3, B3 aceita B2 como raiz. 

B3 soma 1 à distância anunciada por B2 (0) e assim envia (B2, 1, B3) para B5. 

Enquanto isso, B2 aceita Bl como raiz porque esta última tem um ID menor, e envia (B1, 1, B2) 
para B3. 

B5 aceita B1 como raiz e envia (Bl, 1, B5) para B3. 

B3 aceita Bl como raiz e observa que tanto B2 como B5 estão mais próximos da raiz do que ela; 
assim, B3 para de encaminhar mensagens em suas duas interfaces. 


A WN = 


Pon 


Isso deixa B3 com as duas portas não selecionadas, como mostrado na Figura 3.12. 

Mesmo depois que o sistema tiver se estabilizado, a bridge raiz continua a enviar mensagens de 
configuração periodicamente, e as outras bridges continuam a encaminhar essas mensagens conforme 
descrito no parágrafo anterior. Se determinada bridge falha, as bridges seguintes não receberão essas 
mensagens de configuração, e depois de esperar por um período de tempo especificado, elas novamente 
afirmarão ser a raiz, e o algoritmo descrito será disparado novamente para eleger uma nova raiz e novas 
bridges designadas. 

Uma coisa importante a observar é que, embora o algoritmo seja capaz de reconfigurar a spanning 
tree sempre que uma bridge falha, ele não é capaz de encaminhar quadros por caminhos alternativos 
com o objetivo de roteá-los contornando uma bridge congestionada. 


Broadcast e multicast 

A discussão anterior se concentrou no modo como as bridges encaminham quadros unicast de uma 
LAN para outra. Como o objetivo de uma bridge é estender uma LAN de forma transparente por várias 
redes, e como a maioria das LANs admite tanto broadcast quanto multicast, então as bridges também 
precisam ter suporte a esses dois recursos. O broadcast é simples — cada bridge encaminha um quadro 
com um endereço de broadcast como endereço de destino em cada porta ativa (selecionada) diferente 
daquela em que o quadro foi recebido. 

O multicast pode ser implementado exatamente da mesma maneira, com cada host decidindo por 
si mesmo se aceitará a mensagem ou não. É exatamente isso o que é feito na prática. Observe, porém, 
que como nem todas as LANs em uma LAN estendida necessariamente têm um host que é um mem- 
bro de um grupo de multicast em particular, é possível fazer melhor. Especificamente, o algoritmo de 
spanning tree pode ser estendido para podar redes sobre as quais os quadros de multicast não precisam 
ser encaminhados. Considere um quadro enviado ao grupo M por um host na LAN A da Figura 3.12. Se 
não houver host na LAN J que pertençam ao grupo M, então não é preciso que a bridge B4 encaminhe 
os quadros por essa rede. Entretanto, não ter um host na LAN H que pertença ao grupo M não neces- 
sariamente significa que a bridge B1 pode se abster de encaminhar quadros de multicast para a LAN 
H. Tudo depende da existência ou não de membros do grupo M nas LANs I eJ. 

Como determinada bridge descobre se deve encaminhar um quadro de multicast por determinada 
porta? Ela descobre exatamente da mesma forma como uma bridge descobre se deve encaminhar 
um quadro unicast por uma porta em particular - observando os endereços de origem que ela recebe 
por essa porta. Obviamente, os grupos normalmente não são a origem dos quadros, de modo que 
temos que usar um artifício. Em particular, cada host que é membro do grupo M precisa enviar 
periodicamente um quadro contendo o endereço para o grupo M no campo de origem do cabeçalho 
daquele quadro. Esse quadro teria, como seu endereço de destino, o endereço de multicast para as 
bridges. 

Observe que, embora a extensão para suporte a multicast recém-descrita tenha sido proposta, ela 
não é amplamente adotada. Em vez disso, o multicast é implementado exatamente da mesma maneira 
que o broadcast nas LANs estendidas de hoje. 


Limitações das bridges 

A solução baseada em bridge que acabamos de descrever deve ser usada apenas em um ambiente bas- 
tante limitado — para conectar algumas LANs semelhantes. As principais limitações das bridges aparecem 
quando consideramos as questões de escalabilidade e heterogeneidade. 
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VLAN 200 | | VLAN200 


FIGURA 3.13 Duas LANS virtuais compartilham um backbone comum. 


Sobre a questão de escalabilidade, não é realista conectar mais do que algumas poucas LANs por 
meio de bridges, onde, na prática, poucas normalmente significa “dezenas”. Um motivo para isso é 
que o algoritmo de spanning tree escala linearmente, ou seja, não há uma disposição para impor uma 
hierarquia na LAN estendida. Um segundo motivo é que as bridges encaminham todos os quadros 
de broadcast. Embora seja razoável que todos os hosts dentro de um ambiente limitado (digamos, 
um departamento) vejam as mensagens de broadcast um do outro, é improvável que todos os hosts 
em um ambiente maior (digamos, uma grande empresa ou universidade) queiram ser incomodados 
com as mensagens de broadcast uns dos outros. Em outras palavras, o broadcast não escala e, como 
consequência, as LANs estendidas não escalam. 

Uma técnica para aumentar a escalabilidade das LANs estendidas é a LAN virtual (ou VLAN). 
VLANs permitem que uma única LAN estendida seja particionada em várias LANs aparentemente 
separadas. Cada LAN virtual recebe um identificador (às vezes chamado de cor) e os pacotes só podem 
trafegar de um segmento para outro se os dois segmentos tiverem o mesmo identificador. Isso tem 
o efeito de limitar o número de segmentos em uma LAN estendida que receberão qualquer pacote 
de broadcast. 

Vejamos como as VLANs funcionam com um exemplo. A Figura 3.13 mostra quatro hosts em quatro 
segmentos de LAN diferentes. Na ausência de VLANs, qualquer pacote de broadcast de qualquer host 
alcançará os outros hosts. Agora, vamos supor que definimos os segmentos conectados aos hosts W eX 
como estando em uma VLAN, que chamaremos de VLAN 100. Também definimos segmentos conectados 
aos hosts Y e Z como estando na VLAN 200. Para fazer isso, precisamos configurar um identificador de 
VLAN (VLAN ID) em cada porta das bridges B1 e B2. O enlace entre B1 e B2 é considerado como estando 
nas duas VLANSs. 

Quando um pacote enviado pelo host X chega à bridge B2, a bridge observa que ele veio em uma 
porta que estava configurada como estando na VLAN 100. Ela insere um cabeçalho de VLAN entre o 
cabeçalho Ethernet e seu payload. A parte interessante do cabeçalho de VLAN é o VLAN ID; nesse caso, 
o ID é definido como 100. A bridge agora aplica suas regras normais para fazer o encaminhamento ao 
pacote, com a restrição extra de que o pacote não pode ser enviado por uma interface que não faz parte 
da VLAN 100. Assim, sob nenhuma circunstância o pacote — até mesmo um pacote de broadcast — será 
enviado pela interface ligada ao host Z, que está na VLAN 200. Porém, o pacote é encaminhado para a 
bridge B1, que segue as mesmas regras e, portanto, pode encaminhar o pacote ao host W, mas não ao 
host Y. 

Um recurso atraente das VLANS é que é possível mudar a topologia lógica sem mover quaisquer fios 
ou alterar quaisquer endereços. Por exemplo, se quiséssemos fazer com que o segmento conectado ao 
host Z fizesse parte da VLAN 100 e, portanto, fazer com que X, W e Z fiquem na mesma LAN virtual, 
então só precisaríamos mudar uma informação de configuração na bridge B2. 

Sobre a questão da heterogeneidade, as bridges são bastante limitadas nos tipos de redes que elas 
podem interconectar. Em particular, as bridges utilizam o cabeçalho dos quadro da rede e, portanto, 
podem suportar apenas redes que possuem exatamente o mesmo formato para endereços. Assim, 
as bridges podem ser usadas para conectar Ethernets a Ethernets, token rings a token rings, e uma 
rede 802.11 a outra. Também é possível colocar uma ponte entre, digamos, uma Ethernet e uma rede 
802.11, pois as duas redes aceitam o mesmo formato de endereço de 48 bits. Porém, as bridges não são 
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prontamente generalizadas para outros tipos de redes com diferentes formatos de endereçamento, 
como ATM." 

Apesar de suas limitações, as bridges são uma parte muito importante do ambiente completo das 
redes. Sua principal vantagem é que elas permitem que várias LANs sejam conectadas de forma trans- 
parente; ou seja, as redes podem ser conectadas sem que os hosts finais tenham que executar protocolos 
adicionais (ou mesmo que estejam cientes desta conexão, na realidade). A única exceção em potencial é 
quando os hosts precisam anunciar sua inclusão como membros em um grupo de multicast, conforme 
descrito na Seção 3.1.4. 

Observe, porém, que essa transparência pode ser perigosa. Se um host ou, mais precisamente, o 
protocolo de aplicação e transporte sendo executado nesse host, for programado sob a hipótese de que 
ele está operando sobre uma única LAN, então a inserção de bridges entre os hosts de origem e destino 
pode ter consequências inesperadas. Por exemplo, se uma bridge ficar congestionada, ela pode ter que 
descartar quadros; em comparação, é raro que uma única rede Ethernet chegue a descarte um quadro. 
Como outro exemplo, em uma LAN estendida a latência entre qualquer par de hosts fica maior e mais 
altamente variável; em comparação, as limitações físicas de uma única rede Ethernet tornam a latência 
tanto pequena quanto previsível. Como um último exemplo, é possível (embora improvável) que os 
quadros sejam reordenados em uma LAN estendida; em comparação, a ordem dos quadros nunca é 
misturada em uma Ethernet. A conclusão é que nunca é seguro projetar software de rede sob a suposição 
de que ele será executado sobre um único segmento Ethernet. Bridges acontecem. 


3.2 Fundamentos de interligação de redes (IP) A 


Projeto de rede 
Na seção anterior, vimos que era possível montar LANs razoavelmente grandes usando bridges e switches 


de LAN, mas que essas técnicas eram limitadas em sua capacidade de escalar e tratar da heterogeneidade. 
Nesta seção, vamos explorar algumas maneiras de ir além das limitações das redes com bridges, per- 
mitindo-nos montar redes grandes e altamente heterogêneas, com roteamento razoavelmente eficaz. 
Referimo-nos a tais redes como inter-redes. Vamos continuar a discussão de como montar uma inter-rede 
verdadeiramente global no próximo capítulo, mas por enquanto vamos explorar os fundamentos. 
Comecemos considerando mais cuidadosamente o que significa o termo inter-rede. 


3.2.1 O que é uma inter-rede? 


Usamos o termo inter-rede, ou simplesmente internet, com um i minúsculo, para nos referirmos a uma 
coleção qualquer de redes interconectadas para oferecer algum tipo de serviço de entrega de pacotes 
host a host. Por exemplo, uma corporação com muitos sites poderia construir uma inter-rede privada 
interconectando as LANs em seus diferentes locais com enlaces ponto a ponto alugados da compa- 
nhia telefônica. Quando falamos sobre a inter-rede mais utilizada globalmente, à qual uma grande 
porcentagem de redes agora está conectada, nós a chamamos de Internet, com uma letra I maiúscula. 
Seguindo a abordagem deste livro de explicar primeiro os princípios, queremos principalmente que você 
aprenda sobre os princípios da internet com “i minúsculo”, mas ilustramos essas ideias com exemplos 
do mundo real da Internet com “I maiúsculo”. 

Outra parte da terminologia que pode ser confusa é a diferença entre redes, sub-redes e inter-redes. 
Vamos evitar o termo sub-redes (ou subnets) completamente até a Seção 3.2.5. Por enquanto, usamos 
rede para indicar ou uma rede conectada diretamente ou uma rede comutada, do tipo descrito na seção 
anterior e no capítulo anterior. Essa rede usa uma tecnologia, como 802.11 ou Ethernet. Uma inter-rede 
é uma coleção dessas redes interconectadas. Às vezes, para evitar ambiguidade, referimo-nos às redes 
subjacentes que estamos interconectando como redes físicas. Uma inter-rede é uma rede lógica montada 
a partir de uma coleção de redes físicas. Nesse contexto, uma coleção de redes Ethernet conectadas por 
bridges ou switches ainda seria vista como uma única rede. 

A Figura 3.14 mostra um exemplo de inter-rede. Uma inter-rede normalmente é conhecida como 
uma “rede de redes”, pois é composta de muitas redes menores. Nessa figura, vemos redes Ethernet, uma 


“Em certo momento, houve bastante trabalho para fazer com que as redes ATM se comportem mais como redes Ethernet, 
algo chamado Emulação de LAN, para contornar essa limitação, mas isso raramente é visto hoje em dia. 
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Rede 4 (Ethernet) FIGURA 3.14 Uma inter-rede simples. Hn=host; 
Rn=roteador. 
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FIGURA 3.15 Uma inter-rede simples, mostrando as camadas de protocolo usadas para conectar H5 a H8 na Figura 3.14. ETH 
é o protocolo que é executado sobre uma rede Ethernet. 














rede sem fios e um enlace ponto a ponto. Cada uma destas é uma rede que usa uma única tecnologia. 
Os nós que interconectam as redes são chamados roteadores. Eles às vezes também são chamados de 
gateways, mas como esse termo tem várias outras conotações, restringimos nossa notação ao termo 
roteador. 

O Internet Protocol (IP) é a ferramenta chave usada hoje para a criação de inter-redes escaláveis 
e heterogêneas. Ele era conhecido originalmente como protocolo Kahn-Cerf, fazendo referência aos 
nomes de seus inventores.” Um modo de pensar no IP é que ele é executado sobre todos os nós (tanto 
hosts quanto roteadores) em uma coleção de redes e define a infraestrutura que permite que esses nós 
e redes funcionem como uma única inter-rede lógica. Por exemplo, a Figura 3.15 mostra como os hosts 
H5 e H8 estão conectados logicamente pela inter-rede da Figura 3.14, incluindo o grafo de protocolo 
sendo executado em cada nó. Observe que protocolos de nível mais alto, como TCP e UDP normalmente 
operam em cima do IP nos hosts. 

A maior parte do restante deste capítulo trata de diversos aspectos do IP Embora certamente seja 
possível montar uma inter-rede que não use IP - por exemplo, a Novell criou um protocolo de inter-redes 
chamado IPX, que, por sua vez, foi baseado na inter-rede XNS projetada pela Xerox, o IP é o caso mais 
interessante para estudar simplesmente devido ao tamanho da Internet. Em outras palavras, foi somente 


Em 2005, Robert Kahn e Vint Cerf receberam o prêmio A.M. Turing, normalmente conhecido como o Prêmio Nobel da 
ciência da computação, por seu projeto do IP. 
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a Internet IP que realmente enfrentou o problema de escalabilidade. Assim, ela oferece o melhor estudo 
de caso de um protocolo de inter-rede escalável. 


3.2.2 Modelo de serviço 


Um bom lugar para começar quando você monta uma inter-rede é definir seu modelo de serviço, ou seja, 
os serviços host a host que você deseja oferecer. A preocupação principal na definição de um modelo 
de serviço para uma inter-rede é que possamos oferecer um serviço host a host somente se esse serviço 
de alguma maneira puder ser fornecido por cada uma das redes físicas subjacentes. Por exemplo, não 
haveria sentido em decidir que nosso modelo de serviço de inter-rede forneceria entrega garantida de 
cada pacote em 1 ms ou menos se houvesse tecnologias da rede subjacente que pudessem atrasar os 
pacotes arbitrariamente. A filosofia usada na definição do modelo de serviço do IP portanto, foi torná-lo 
básico o suficiente para que qualquer tecnologia de rede que pudesse aparecer em uma inter-rede fosse 
capaz de oferecer o serviço necessário. 

O modelo de serviço do IP pode ser imaginado como tendo duas partes: um esquema de endereça- 
mento, que oferece um modo de identificar todos os hosts na inter-rede, e um modelo de datagrama (sem 
conexão) da entrega de dados. Esse modelo de serviço também é chamado de melhor esforço porque, 
embora o IP faça todo o esforço possível para entregar os datagramas, ele não oferece garantias de que 
irá de fato fazê-lo. Adiamos uma discussão do esquema de endereçamento por enquanto e examinamos 
primeiro o modelo de entrega de dados. 


Entrega de datagrama 

O datagrama IP é fundamental para o Internet Protocol. Lembre-se, da Seção 3.1.1, que um datagrama é 
um tipo de pacote que é enviado de uma forma sem conexão por uma rede. Cada datagrama transporta 
informações suficientes para permitir que a rede encaminhe o pacote ao seu destino correto; não é 
preciso qualquer mecanismo de configuração antecipado para dizer à rede o que fazer quando o pacote 
chegar. Você simplesmente o envia e a rede faz seu melhor esforço para levá-lo ao destino desejado. A 
parte do “melhor esforço” significa que, se algo sair errado e o pacote for perdido, modificado, encami- 
nhado erroneamente ou deixar de chegar ao seu destino desejado por algum outro motivo, a rede não 
faz nada — ela se esforçou ao máximo, e isso é tudo o que ela precisa fazer. Ela não faz qualquer tentativa 
de recuperar-se da falha. Isso também é conhecido como serviço não confiável. 

O serviço de melhor esforço e sem conexão e praticamente o serviço mais simples que você poderia 
pedir de uma inter-rede, e esse é um ótimo ponto forte do IP. Por exemplo, se você oferecer o serviço 
de melhor esforço sobre uma rede que oferece um serviço confiável, então não há problemas — você 
acaba ficando com um serviço de melhor esforço que sempre entregará os pacotes. Se, por outro lado, 
você tivesse um modelo de serviço confiável sobre uma rede não confiável, teria que incluir muita 
funcionalidade extra nos roteadores para compensar as deficiências da rede subjacente. Manter os 
roteadores o mais simples possível foi um dos objetivos de projeto originais do IP 

A capacidade do IP de “ser executado sobre qualquer coisa” é constantemente citada como uma de 
suas características mais importantes. É interessante observar que muitas das tecnologias sobre as quais 
o IP é executado hoje não existiam quando o IP foi inventado. Até o momento, nenhuma tecnologia de 
rede inventada se provou ser muito estranha para o IP; foi dito até mesmo que o IP pode ser executado 
sobre uma rede que transporta mensagens usando pombos-correios. 

A entrega de melhor esforço não apenas significa que os pacotes podem ser perdidos. Às vezes, eles 
podem ser entregues fora de ordem, e às vezes o mesmo pacote pode ser entregue mais de uma vez. Os 
protocolos ou aplicações de nível mais alto que operam acima do IP precisam estar cientes de todos 
esses modos de falha possíveis. 


Formato de pacote 

Claramente, uma parte importante do modelo de serviço do IP é o tipo dos pacotes que podem ser trans- 
portados. O datagrama IP como a maior parte dos pacotes, consiste em um cabeçalho seguido por um 
número de bytes de dados. O formato do cabeçalho é mostrado na Figura 3.16. Observe que adotamos 
um estilo para representar os pacotes diferente daquele usado nos capítulos anteriores. Isso porque os 
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FIGURA 3.16 Cabeçalho do pacote IPv4. 


formatos de pacote na camada de inter-rede e superiores, onde estaremos focalizando nossa atenção 
nos próximos capítulos, são quase invariavelmente projetados para serem alinhados em limites de 32 
bits, para simplificar a tarefa de processá-los em software. Assim, o modo comum de representá-los 
(usado nas Requests for Comments (RFCs) da Internet, por exemplo) é desenhá-los como uma sucessão 
de palavras de 32 bits. A palavra no topo é aquela transmitida primeiro, e o byte mais à esquerda de 
cada palavra é aquele transmitido primeiro. Nessa representação, você pode facilmente reconhecer que 
o comprimento dos campos são múltiplos de 8 bits. Nos casos pouco comuns em que os campos não 
são múltiplos exatos de 8 bits, você pode determinar os tamanhos dos campos examinando as posições 
de bit marcadas no alto do pacote. 

Examinando cada campo no cabeçalho IP vemos que o modelo “simples” da entrega de datagrama 
usando melhor esforço ainda tem alguns recursos sutis. O campo Versão especifica a versão do IP A 
versão atual do IP é 4, e por isso ele é chamado IPv4.” Observe que colocar esse campo bem no início do 
datagrama facilita para tudo o mais no formato do pacote seja redefinido em versões subsequentes; o 
software de processamento do cabeçalho começa examinando a versão e depois decide como processar 
o restante do pacote de acordo com o formato apropriado. O próximo campo, TamCab, especifica o 
tamanho do cabeçalho em palavras de 32 bits. Quando não existem opções, o que acontece quase 
sempre, o cabeçalho possui 5 palavras (20 bytes) de comprimento. O campo TOS (Type of Service ou 
Tipo de Serviço) de 8 bits teve uma série de definições diferentes com o passar dos anos, mas sua função 
básica é permitir que os pacotes sejam tratados de formas diferentes com base nas necessidades da 
aplicação. Por exemplo, o valor do TOS poderia determinar se um pacote deve ou não ser colocado em 
uma fila especial na qual é introduzido pouco atraso. Discutimos o uso desse campo (que evoluiu um 
pouco com o passar dos anos) com mais detalhes nas Seções 6.4.2 e 6.5.3. 

Os próximos 16 bits do cabeçalho contêm o Comprimento do datagrama, incluindo o cabeçalho. 
Diferente do campo TamCab, o campo Comprimento conta número de bytes em vez de número de 
palavras. Assim, o tamanho máximo de um datagrama IP é 65.535 bytes. A rede física sobre a qual o 
IP está sendo executado, porém, pode não aceitar pacotes tão grandes. Por esse motivo, o IP provê 
suporte a um processo de fragmentação e remontagem. A segunda palavra do cabeçalho contém in- 
formações sobre fragmentação, e os detalhes de seu uso são apresentados na próxima seção, intitulada 
“Fragmentação e remontagem”. 

Prosseguindo para a terceira palavra do cabeçalho, o próximo byte é o campo de tempo de vida, TTL 
(Time To Live). Seu nome reflete seu significado histórico, ao invés do modo como ele normalmente é usado 
hoje. A intenção do campo é identificar pacotes que tenham sido roteados em círculos e descartá-los, em 


"O próximo número de versão principal do IP que é discutido no Capítulo 4, tem o novo número de versão 6 e é conhecido 
como IPv6. O número de versão 5 foi usado para um protocolo experimental chamado ST-II, que não foi amplamente 
utilizado. 
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vez de deixar que eles consumam recursos indefinidamente. Originalmente, o campo TTL era preenchido 
com um número específico de segundos durante o qualo pacote teria permissão para viver, e os roteadores 
ao longo do caminho diminuiriam esse campo até que chegasse a 0. Porém, como era raro que um pacote 
ficasse por 1 segundo em um roteador, e nem todos os roteadores tinham acesso a um relógio em comum, 
a maioria dos roteadores simplesmente decrementava o TTL em 1 quando encaminhava o pacote. Assim, 
ele tornou-se mais um contador de hops do que um temporizador, que ainda é uma forma perfeitamente 
válida de identificar pacotes que estejam presos em um roteamento em círculos. Uma sutileza está no 
valor inicial desse campo dado pelo host emissor: se ele for muito alto, os pacotes podem ficar circulando 
por muito tempo antes de serem descartados; se ele for muito baixo, os pacotes podem não chegar ao seu 
destino. O valor 64 é o padrão atual. 

O campo Protocolo é simplesmente uma chave de demultiplexação que identifica o protocolo de 
mais alto nível ao qual esse pacote IP deverá ser entregue. Existem valores definidos para o TCP (Trans- 
mission Control Protocol- 6), UDP (User Datagram Protocol — 17) e muitos outros protocolos que podem 
ficar acima do IP no grafo de protocolos. 

A SomaDeVerificação é calculada considerando-se o cabeçalho IP inteiro como uma sequência de 
palavras de 16 bits, somando-as usando a aritmética de complemento de um e tomando o complemento 
de um do resultado. Esse é o algoritmo de soma de verificação IP descrito na Seção 2.4. Assim, se qualquer 
bit no cabeçalho for modificado em trânsito, a soma de verificação não terá o valor correto quando o 
pacote for recebido. Como um cabeçalho adulterado pode conter um erro no endereço de destino — e, 
como resultado, pode ter sido entregue no lugar errado —, faz sentido descartar qualquer pacote que 
falhe na soma de verificação. Deve-se observar que esse tipo de soma de verificação não tem as mesmas 
propriedades fortes de detecção de erros de um CRC, mas é muito mais fácil de calcular em software. 

Os dois últimos campos exigidos no cabeçalho são o EndereçoOrigem e o EndereçoDestino para o 
pacote. O segundo é a chave para a entrega do datagrama: cada pacote contém um endereço completo 
para o seu destino alvo, de modo que as decisões de encaminhamento possam ser tomadas em cada 
roteador. O endereço de origem é necessário para permitir que os destinatários decidam se desejam 
aceitar o pacote e para permitir que eles enviem uma resposta. Os endereços IP são discutidos na Seção 
3.2.3 — por enquanto, o importante a saber é que o IP define seu próprio espaço de endereços globais, 
independentemente das redes físicas sobre as quais ele atua. Conforme veremos, essa é uma das chaves 
para dar suporte à heterogeneidade. 

Finalmente, pode haver uma série de opções no final do cabeçalho. A presença ou ausência de opções 
pode ser determinada examinando-se o campo de tamanho do cabeçalho (TamCab). Embora as opções 
sejam usadas muito raramente, uma implementação IP completa precisa ser capaz de tratar todas elas. 


Fragmentação e remontagem 
Um dos problemas de fornecer um modelo de serviço host a host uniforme sobre uma coleção 
heterogênea de redes é que cada tecnologia de rede costuma ter sua própria ideia do tamanho que 
um pacote pode ter. Por exemplo, uma rede Ethernet pode aceitar pacotes de até 1.500 bytes de 
comprimento, enquanto pacotes FDDI (Fiber Distributed Data Interface) podem ter 4.500 bytes 
de comprimento. Isso deixa duas escolhas para o modelo de serviço do IP: garantir que todos os 
datagramas IP sejam pequenos o suficiente para caber dentro de um pacote em qualquer tecnologia 
de rede ou fornecer um meio pelo qual os pacotes possam ser fragmentados e remontados quando 
forem muito grandes para forem transmitidos por determinada tecnologia de rede. A última é uma 
boa escolha, especialmente quando você considera o fato de que novas tecnologias de rede sempre 
estão aparecendo, e o IP precisa ser executado sobre todas elas; isso tornaria difícil escolher um limite 
adequadamente pequeno para o tamanho do datagrama. Isso também significa que um host não 
enviará pacotes desnecessariamente pequenos, o que desperdiçaria largura de banda e consumiria 
recursos de processamento, exigindo mais cabeçalhos por byte de dados enviado. Por exemplo, 
dois hosts conectados a redes FDDI que estão interconectadas por um enlace ponto a ponto não 
precisariam enviar pacotes pequenos o suficiente para caber em uma rede Ethernet. 

A ideia central aqui é que cada tipo de rede tenha uma unidade máxima de transmissão (MTU — 
Maximum Transmission Unit), que é o maior datagrama IP que ela pode transportar em um quadro. 





Capítulo 3  nterconexão de redes 129 
PRM 
ELSEVIER 


H5S H8 


R1 R2 R3 


oe ED e 


802.11| IP | 1400 ETH | IP | 1400 PPP |IP| 512 ETH | IP | 512 


PPP|IP| 512 ETH [IP | 512 








PPP |IP| 512 ETH | IP | 512 





FIGURA 3.17 Datagramas IP atravessando a sequência de redes físicas representadas graficamente na Figura 3.14. 


Observe que esse valor é menor que o maior tamanho de pacote nessa rede, pois o datagrama IP precisa 
caber no campo de payload do quadro da camada de enlace.? 

Quando um host envia um datagrama IP portanto, ele pode escolher qualquer tamanho que de- 
sejar. Uma escolha razoável é o MTU da rede à qual o host está diretamente conectado. Desta forma, 
a fragmentação só será necessária se o caminho até o destino incluir uma rede com um MTU menor. 
Porém, se o protocolo de transporte que opera acima do IP der ao IP um pacote maior do que o MTU 
local, então o host de origem deverá fragmentá-lo. 

A fragmentação normalmente ocorre em um roteador quando ele recebe um datagrama que precisa 
ser encaminhado por uma rede que tem um MTU menor do que o datagrama recebido. Para permitir que 
esses fragmentos sejam remontados no host receptor, todos eles transportam o mesmo identificador no 
campo Ident. Esse identificador é escolhido pelo host de envio e espera-se que ele seja exclusivo entre 
todos os datagramas que poderiam chegar no destino provenientes dessa origem por um período de 
tempo razoável. Como todos os fragmentos do datagrama original contêm esse identificador, o host que 
fará a remontagem será capaz de reconhecer os fragmentos que devem ser agrupados. Se nem todos 
os fragmentos chegarem ao host receptor, o host abre mão do processo de remontagem e descarta os 
fragmentos que chegaram. O IP não tenta se recuperar da perda de fragmentos. 

Para ver o que tudo isso significa, considere o que acontece quando o host H5 envia um datagrama 
ao host H8 na inter-rede de exemplo mostrada na Figura 3.14. Supondo que a MTU seja de 1.500 bytes 
para as duas redes Ethernet e para a rede 802.11, e de 532 bytes para a rede ponto a ponto, então um 
datagrama de 1.420 bytes (cabeçalho IP de 20 bytes mais 1.400 bytes de dados) enviado por H5 atravessa 
a rede 802.11 e a primeira Ethernet sem fragmentação, mas precisa ser fragmentado em três datagramas 
no roteador R2. Esses três fragmentos são então encaminhados pelo roteador R3 pela segunda Ethernet 
até o host de destino. Essa situação é ilustrada na Figura 3.17. Essa figura também serve para reforçar 
dois pontos importantes: 


1. Cada fragmento é, por si só, um datagrama IP autocontido, que é transmitido por uma sequência 
de redes físicas, independente dos outros fragmentos. 
2. Cada datagrama IP é reencapsulado para cada rede física pela qual ele atravessa. 


O processo de fragmentação pode ser entendido com detalhes examinando-se os campos de cabeça- 
lho de cada datagrama, como é feito na Figura 3.18. O pacote não fragmentado, mostrado no topo, tem 
1.400 bytes de dados e um cabeçalho IP de 20 bytes. Quando o pacote chega no roteador R2, que tem uma 
MTU de 532 bytes, ele precisa ser fragmentado. Uma MTU de 532 bytes deixa 512 bytes para dados após 
o cabeçalho IP de 20 bytes, de modo que o primeiro fragmento contém 512 bytes de dados. O roteador 
coloca em 1 o bit M no campo Flags (ver Figura 3.16), significando que existem mais fragmentos a seguir, 


“Em redes ATM, o MTU, felizmente, é muito maior do que uma única célula, pois o ATM tem seus próprios mecanismos 
de fragmentação. O quadro da camada de enlace no ATM é chamado de unidade de dados de protocolo da subcamada de 
convergência (CS-PDU - Convergence Sublayer Protocol Data Unit). 
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(a) Eca a Sal FIGURA 3.18 Campos de cabeçalho usados na fragmentação IP: (a) pacote não 
no cotacesano fragmentado; (b) pacotes fragmentados. 
Ident=x O Desl.=0 


Restante do cabeçalho 


1400 bytes de dados 


(b) Início do cabeçalho 
Ident=x 1 Desl. = 0 


Restante do cabeçalho 


512 bytes de dados 


Início do cabeçalho 
Ident=x 1 Desl.=64 


Restante do cabeçalho 


512 bytes de dados 


Início do cabeçalho 
Ident =x O Desl. = 128 


Restante do cabeçalho 


376 bytes de dados 


e define o Deslocamento como 0, pois esse fragmento contém a primeira parte do datagrama original. 
Os dados transportados no segundo fragmento começam com o 513º byte dos dados originais, de modo 
que o campo Deslocamento nesse cabeçalho é definido como 64, que corresponde a 512 + 8. Por que a 
divisão por 8º Porque os projetistas do IP decidiram que a fragmentação sempre deve acontecer em limites 
de 8 bytes, o que significa que o campo Deslocamento conta pedaços de 8 bytes, e não bytes. (Deixamos 
como um exercício ao leitor descobrir por que foi tomada essa decisão de projeto.) O terceiro fragmento 
contém os últimos 365 bytes de dados, e o deslocamento agora é 2 x 512 + 8= 128. Como esse é o último 
fragmento, o bit M é fixado em 0. 

Observe que o processo de fragmentação é feito de modo que pudesse ser repetido se um fragmento 
chegasse em outra rede com um MTU ainda menor. A fragmentação produz datagramas IP menores, 
válidos, que podem ser facilmente remontados para recuperar o datagrama original ao ser recebido, 
independentemente da ordem de sua chegada. A remontagem é feita no host receptor e não em cada 
roteador. 

A remontagem IP está longe de ser um processo simples. Por exemplo, se um único fragmento for 
perdido, o receptor ainda tentará remontar o datagrama, e ele eventualmente abortará a tentativa e terá 
que desalocar os recursos que foram usados para realizar a remontagem que falhou.º Por esse motivo, 
entre outros, a fragmentação IP geralmente é considerada algo bom de se evitar. Atualmente, os hosts 
são fortemente encorajados a realizar a “descoberta de MTU do caminho”, um processo por meio do 
qual a fragmentação é evitada porque os pacotes enviados são pequenos o suficiente para atravessar o 
enlace com o menor MTU no caminho do emissor ao receptor. 


Conforme veremos no Capítulo 8, fazer com que um host aloque recursos desnecessariamente pode ser a base 
de um ataque de negação de serviço. 
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3.2.3 Endereços globais 


Na discussão anterior do modelo de serviço do IP mencionamos que uma das coisas que ele oferece é um 
esquema de endereçamento. Afinal, se você quiser poder enviar dados para qualquer host em qualquer 
rede, é preciso que haja um modo de identificar todos os hosts. Assim, precisamos de um esquema de 
endereçamento global - um em que dois hosts não tenham o mesmo endereço. A exclusividade global 
é a primeira propriedade que deve ser fornecida em um esquema de endereçamento.!º 

Os endereços Ethernet são globalmente exclusivos, mas isso apenas não basta para um esquema de 
endereçamento em uma inter-rede grande. Os endereços Ethernet também são planos, o que significa 
que eles não possuem estrutura e oferecem muito poucas dicas para os protocolos de roteamento. (Na 
realidade, os endereços Ethernet possuem uma estrutura para fins de atribuição — os primeiros 24 bits 
identificam o fabricante —, mas isso não oferece informações úteis para protocolos de roteamento, 
pois essa estrutura não tem nada a ver com a topologia da rede.) Em comparação, os endereços IP são 
hierárquicos, significando que eles são compostos de várias partes que correspondem a algum tipo de 
hierarquia na inter-rede. Especificamente, os endereços IP consistem em duas partes, normalmente 
chamadas de parte de rede e parte de host. Essa é uma estrutura bastante lógica para uma inter-rede, 
que é composta de muitas redes interconectadas. A parte de rede de um endereço IP identifica a rede à 
qual o host está conectado; todos os hosts conectados à mesma rede possuem a mesma parte de rede 
em seu endereço IP A parte de host, então, identifica cada host exclusivamente nessa rede em particular. 
Assim, na inter-rede simples da Figura 3.14, todos os endereços dos hosts na rede 1, por exemplo, teriam 
a mesma parte de rede e diferentes partes de host. 

Observe que os roteadores na Figura 3.14 estão conectados a duas redes. Eles precisam ter um 
endereço em cada rede, um para cada interface. Por exemplo, o roteador R1, que fica entre a rede sem 
fios e uma rede Ethernet, tem um endereço IP na interface com a rede sem fios cuja parte de rede é a 
mesma de todos os hosts nessa rede. Ele também tem um endereço IP na interface com a rede Ethernet 
que tem a mesma parte de rede dos hosts nessa Ethernet. Assim, lembrando que um roteador poderia 
ser implementado como um host com duas interfaces de rede, é mais exato pensar nos endereços IP 
como pertencentes a interfaces do que a hosts. 

Agora, como esses endereços hierárquicos são representados? Diferente de algumas outras formas de 
endereço hierárquico, o tamanho das duas partes não são iguais para todos os endereços. Originalmente, 
os endereços IP eram divididos em três classes diferentes, como mostra a Figura 3.19, cada uma definindo 
as partes de rede e de host com diferentes tamanhos fixos. (Há também os endereços de classe D, que 
especificam um grupo de multicast, discutido na Seção 4.2, e endereços de classe E, que atualmente 
não são usados.) Em todos os casos, o endereço tem 32 bits de extensão. 

A classe de um endereço IP era identificada usando poucos dos bits mais significativos. Se o primeiro 
bit fosse 0, este era um endereço de classe A. Se o primeiro bit fosse 1 e o segundo fosse 0, este era um 
endereço de classe B. Se os dois primeiros bits fossem 11 e o terceiro bit fosse 0, este era um endereço 
de classe C. Assim, dos aproximadamente 4 bilhões de endereços IP possíveis, metade eram de classe 


(a) 7 24 
0 Rede Host 

(b) 14 16 
1.0 Rede Host 

(c) 21 8 
1/10 Rede Host 


FIGURA 3.19 Endereços IP: (a) classe A; (b) classe B; (c) classe C. 


10Dependendo de como se vê as coisas, o endereçamento global não é mais garantido na Internet moderna, por diversos 
motivos, explicados na Seção 4.1. 
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A, um quarto de classe B e um oitavo de classe C. Cada classe alocava certo número de bits para a parte 
de rede do endereço e o restante para a parte de host. As redes de classe A possuíam 7 bits para a parte 
de rede e 24 bits para a parte de host, significando que só podia haver 126 redes de classe A (os valores 0 
e 127 eram reservados), mas cada um deles poderia acomodar até 224 — 2 (cerca de 16 milhões) de hosts 
(novamente, existiam dois valores reservados). Os endereços de classe B alocavam 14 bits para a rede e 
16 bits para o host, significando que cada rede de classe B tinha espaço para 65.534 hosts. Finalmente, 
os endereços de classe C tinham apenas 8 bits para o host e 21 para a parte de rede. Portanto, uma rede 
de classe C poderia ter apenas 256 identificadores de host distintos, o que significava somente 254 hosts 
conectados (um identificador de host, 255, era reservado para broadcast, e O não era um número de 
host válido). Porém, o esquema de endereçamento admitia 22! redes de classe C. 

Diante disso, esse esquema de endereçamento tem bastante flexibilidade, permitindo que redes 
de tamanhos muito diferentes sejam acomodadas de modo bastante eficiente. A ideia original era que 
a Internet consistisse em um pequeno número de redes remotas (estas seriam redes de classe A), um 
número modesto de redes com tamanho médio, como universidades (estas seriam redes de classe B), 
e um número grande de LANS (estas seriam redes de classe C). Porém, isso se provou não ser flexível o 
suficiente, como veremos em breve. Hoje, os endereços IP normalmente “não têm classe”; os detalhes 
disso são explicados mais adiante. 

Antes de examinarmos como os endereços IP são usados, é útil examinar algumas questões práticas, 
por exemplo, como você os escreve. Por convenção, os endereços IP são escrito como quatro inteiros 
decimais separados por pontos.!! Cada inteiro representa o valor decimal contido em 1 byte do endereço, 
começando no mais significativo. Por exemplo, o endereço do computador em que esta sentença foi 
digitada é 171.69.210.245. 

É importante não confundir endereços IP com nomes de domínio da Internet, que também são 
hierárquicos. Os nomes de domínio costumam ser sequências de caracteres ASCII separadas por pontos, 
como em cs.princeton.edu. Falaremos sobre eles na Seção 9.3.1. O importante sobre endereços IP é que 
eles são o que é transportado nos cabeçalhos dos pacotes IP e são esses endereços que são usados nos 
roteadores IP para tomar decisões de encaminhamento. 


3.2.4 Encaminhamento de datagrama no IP 


Agora estamos prontos para examinar o mecanismo básico pelo qual os roteadores IP encaminham 
pacotes em uma inter-rede. Lembre-se, da Seção 3.1, que o encaminhamento é o processo de tomar 
um pacote de uma entrada e enviá-lo pela saída apropriada, enquanto o roteamento é o processo de 
construir as tabelas que permitem determinar a saída correta para um pacote. A discussão aqui focaliza 
o encaminhamento; analisamos o roteamento na Seção 3.3. 

Os principais pontos que se deve ter em mente quando discutimos o encaminhamento de datagramas 
IP são os seguintes: 


e Cada datagrama IP contém o endereço IP do host de destino. 

e Aparte de rede de um endereço IP identifica exclusivamente uma única rede física que faz parte 
da Internet maior. 

e Todos os hosts e roteadores que compartilham a mesma parte de rede em seus endereços são 
conectados à mesma rede física e, portanto, podem se comunicar uns com os outros enviando 
quadros por essa rede. 

e Toda rede física que faz parte da Internet tem pelo menos um roteador que, por definição, 
também está conectado a pelo menos uma outra rede física; esse roteador pode trocar pacotes 
com hosts ou roteadores em qualquer uma das redes. 


O encaminhamento de datagramas IP portanto, pode ser tratado da seguinte forma. Um datagrama 
é enviado de um host de origem para um host de destino, possivelmente passando por vários roteadores 
ao longo do caminho. Qualquer nó, seja ele um host ou um roteador, primeiro tenta determinar se está 
conectado à mesma rede física do destino. Para fazer isso, ele compara a parte de rede do endereço de 


HEsta notação é conhecida como “notação decimal com pontos”. (N.T.) 
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destino com a parte de rede do endereço de cada uma de suas interfaces de rede. (Os hosts normalmente 
têm apenas uma interface, enquanto os roteadores normalmente têm duas ou mais, pois eles estão 
normalmente conectados a duas ou mais redes.) Se houver uma correspondência, então isso significa 
que o destino se encontra na mesma rede física da interface, e o pacote pode ser entregue diretamente 
por essa rede. A Seção 3.2.6 explica alguns dos detalhes desse processo. 

Se o nó de origem não estiver conectado à mesma rede física que o nó de destino, então ele precisa 
enviar o datagrama para um roteador. Em geral, cada nó poderá escolher entre diversos roteadores, de 
modo que ele precisa escolher o melhor ou, pelo menos, um que tenha uma chance razoável de levar o 
datagrama para mais próximo do seu destino. O roteador que ele escolhe é conhecido como roteador 
de próximo salto. O roteador encontra o próximo salto correto consultando sua tabela de encami- 
nhamento. A tabela de encaminhamento é conceitualmente apenas uma lista de pares (NúmeroRede, 
PróximoSalto). (Como veremos a seguir, as tabelas de encaminhamento na prática geralmente contêm 
alguma informação adicional relacionada ao próximo salto.) Normalmente, há também um roteador 
padrão que é usado se nenhuma das entradas da tabela corresponder ao número da rede de destino. 
Para um host, pode ser bastante aceitável ter um roteador padrão e nada mais — isso significa que todos 
os datagramas destinados aos hosts que não estejam na mesma rede física à qual o host emissor está 
conectado serão enviados pelo roteador padrão. 

Podemos descrever o algoritmo de encaminhamento de datagrama da seguinte maneira: 


se (NúmeroRede do destino = NúmeroRede de uma das minhas interfaces) então 
entrega pacote ao destino por essa interface 
senão 


se (NúmeroRede do destino está na minha tabela de encaminhamento) então 
entrega pacote ao roteador de PróximoSalto 

senão 

entrega pacote ao roteador padrão 


Para um host com apenas uma interface e apenas um roteador padrão em sua tabela de encami- 
nhamento, isso é simplificado para 


se (NúmeroRede de destino = meu NúmeroRede) então 
entrega pacote diretamente ao destino 

senão 

entrega pacote ao roteador padrão 


Vejamos agora como isso funciona na inter-rede de exemplo da Figura 3.14. Primeiro, suponha que 
H1 queira enviar um datagrama para H2. Como eles estão na mesma rede física, H1 e H2 têm o mesmo 
número de rede em seu endereço IP Assim, H1 deduz que pode entregar o datagrama diretamente a H2 
pela rede Ethernet. A única questão que precisa ser resolvida é como H1 descobre o endereço Ethernet 
correto de H2 — esse é o mecanismo de resolução de endereços descrito na Seção 3.2.6. 


BRIDGES, SWITCHES E ROTEADORES 





É fácil confundir-se com a distinção entre bridges, switches e roteadores. Existe um bom motivo para 

essa confusão, pois, em algum nível, todos eles encaminham mensagens de um enlace para outro. Uma 
distinção que as pessoas fazem é baseada na disposição de camadas. Bridges são nós no nível de enlace (eles 
encaminham quadros de um enlace para outro a fim de implementar uma LAN estendida), switches são 

nós no nível de rede (eles encaminham pacotes de um enlace para outro a fim de implementar uma rede de 
comutação de pacotes) e roteadores são nós em nível de inter-rede (eles encaminham datagramas de uma 
rede para outra a fim de implementar uma inter-rede). 

A distinção entre bridges e switches agora é bastante obsoleta. Por exemplo, já vimos que uma bridge 
multiportas normalmente é chamada de switch Ethernet ou switch de LAN. Por esse motivo, bridges e 
switches normalmente são agrupados como “dispositivos da camada 2”, onde a camada 2 nesse contexto 
significa “acima da camada física, abaixo da camada de inter-rede”. 
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Historicamente, tem havido distinções importantes entre switches de LAN (ou bridges) e switches de 
WAN (como aqueles baseados em ATM ou Frame Relay). Switches de LAN tradicionalmente dependem 
do algoritmo de spanning tree, enquanto os switches de WAN geralmente executam protocolos de 
roteamento que permitem que cada switch descubra a topologia da rede inteira. Essa é uma distinção 
importante, pois conhecer a topologia da rede inteira permite aos switches distinguir entre diversas rotas, 
enquanto, por outro lado, o algoritmo de spanning tree fixa uma única árvore sobre a qual as mensagens são 
encaminhadas. Também acontece que o algoritmo de spanning tree não escala muito bem. Novamente, essa 
distinção perde um pouco o sentido à medida que protocolos de roteamento de longa distância começam 
a ganhar espaço em switches de LAN. 

E os switches e roteadores? Internamente, eles parecem ser muito semelhantes (como ilustrará a 
seção sobre implementações de switches e roteadores). A principal distinção é o tipo de pacote que eles 
encaminham: datagramas IP no caso de roteadores e pacotes da Camada 2 (quadros Ethernet ou células 
ATM) no caso de switches. 

Uma grande diferença entre uma rede construída usando switches e a Internet construída usando 
roteadores é que a Internet é capaz de acomodar a heterogeneidade, enquanto as redes comutadas 
normalmente consistem em enlaces homogêneos. Esse suporte à heterogeneidade é um dos principais 
motivos pelos quais a Internet é tão utilizada. Também é o fato de o IP operar sobre praticamente qualquer 
outro protocolo (incluindo ATM e Ethernet) que faz com que agora esses protocolos sejam vistos como 
tecnologias da Camada 2. 





Agora, suponha que H5 queira enviar um datagrama para H8. Como esses hosts estão em redes 
físicas diferentes, eles possuem números de rede diferentes, de modo que H5 deduz que precisa enviar 
o datagrama para um roteador. R1 é a única escolha — o roteador padrão -, de modo que H1 envia o 
datagrama através da rede sem fios para R1. De modo semelhante, R1 sabe que não pode entregar um 
datagrama diretamente para H8 porque nenhuma das interfaces de R1 está na mesma rede de H8. 
Suponha que o roteador padrão de R1 seja R2; R1 então envia o datagrama para R2 pela rede Ethernet. 
Supondo que R2 tenha a tabela de encaminhamento mostrada na Tabela 3.5, ele procura pelo número 
de rede de H8 (rede 4) e encaminha o datagrama pela rede ponto a ponto para R3. Finalmente, R3, por 
estar na mesma rede de H8, encaminha o datagrama diretamente para H8. 

Observe que é possível incluir na tabela de encaminhamento as informações sobre redes diretamente 
conectadas. Por exemplo, poderíamos rotular as interfaces de rede do roteador R2 como interface 0 para 
o enlace ponto a ponto (rede 3) e interface 1 para a rede Ethernet (rede 2). Então, R2 teria a tabela de 
encaminhamento mostrada na Tabela 3.6. 

Assim, para qualquer número de rede que R2 encontre em um pacote, ele saberá o que fazer. Ou essa 
rede está conectada diretamente a R2, caso em que o pacote poderá ser entregue ao seu destino por 
essa rede, ou a rede pode ser alcançada por meio de algum roteador do próximo salto, que R2 pode 


Tabela 3.5 Exemplo de tabela de encaminhamento para roteador R2 da Figura 3.14 





NúmeroRede PróximoSalto 
1 R1 
4 R3 


Tabela 3.6 Tabela de encaminhamento completa para roteador R2 da Figura 3.14 





NúmeroRede PróximoSalto 
1 R1 

2 Interface 1 

3 Interface O 

4 R3 
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alcançar por uma rede à qual está conectado. De qualquer forma, R2 usará o mecanismo de ARP des- 
crito a seguir, para determinar o endereço MAC do nó para o qual o pacote é enviado em seguida. 

A tabela de encaminhamento usada por R2 é simples o suficiente para que possa ser configurada 
manualmente. Porém, normalmente, essas tabelas são mais complexas e seriam construídas execu- 
tando-se um protocolo de roteamento como aquele descrito na Seção 3.3. Observe também que, na 
prática, os números de rede normalmente são maiores (por exemplo, 128.96).!2 

Agora podemos ver como o endereçamento hierárquico — dividir o endereço em partes de rede e 
host — melhorou a escalabilidade de uma rede grande. Os roteadores agora contêm tabelas de encami- 
nhamento que listam apenas um conjunto de números de rede ao invés de todos os nós na rede. Em 
nosso exemplo simples, isso significava que R2 poderia armazenar as informações necessárias para 
alcançar todos os hosts na rede (havia oito) em uma tabela com quatro entradas. Mesmo que houvesse 
100 hosts em cada rede física, R2 ainda precisaria apenas dessas mesmas quatro entradas. Esse é um 
bom primeiro passo (embora, de forma alguma, o último) para se alcançar escalabilidade. 


Isso ilustra um dos princípios mais importantes da montagem de redes escaláveis: para conseguir 
escalabilidade, você precisa reduzir a quantidade de informações que são armazenadas em cada nó e 
que são trocadas entre os nós. A forma mais comum de fazer isso é a agregação hierárquica. O IP introduz 


uma hierarquia de dois níveis, com redes no nível superior e nós no nível inferior. Agregamos informações 
permitindo que os roteadores tratem apenas de alcançar a rede correta; a informação que um roteador 
precisa para entregar um datagrama a qualquer nó em determinada rede é representada por uma única 
informação agregada. 





3.2.5 Sub-redes e endereçamento sem classes 


A intenção original dos endereços IP era que a parte da rede identificasse exclusivamente uma rede 
física exata. Acontece que essa técnica tem algumas desvantagens. Imagine um grande campus que 
possui muitas redes internas e decide se conectar à Internet. Para cada rede, não importando o quão 
pequena ela seja, é preciso pelo menos de um endereço de rede de classe C. Pior ainda, para qualquer 
rede com mais de 255 hosts, é necessário um endereço de classe B. Isso pode não parecer grande 
coisa, e realmente não era quando a Internet foi idealizada inicialmente, mas existe um número finito 
de números de rede, e existem muito menos endereços de classe B do que de classe C. Os endereços de 
classe B tendem a ter uma demanda particularmente alta, pois você nunca sabe se sua rede pode se 
expandir para além de 255 nós, de modo que é mais fácil usar um endereço de classe B desde o início do 
que ter que renumerar cada host quando estiver sem espaço em uma rede de classe C. O problema que 
observamos aqui é a ineficiência da atribuição de endereços: uma rede com dois nós usa um endereço 
de rede inteiro de classe C, desperdiçando, assim, 253 endereços perfeitamente úteis; uma rede de classe 
B com pouco mais de 255 hosts desperdiça mais de 64.000 endereços. 

A atribuição de um número de rede por rede física, portanto, utiliza o espaço de endereços IP poten- 
cialmente muito mais rápido do que gostaríamos. Embora precisássemos conectar mais de 4 bilhões de 
hosts para acabar com todos os endereços válidos, só precisamos conectar 2!4 (cerca de 16.000) redes 
de classe B antes que essa parte do espaço de endereços se esgote. Portanto, gostaríamos de encontrar 
alguma maneira de usar os números de rede de forma mais eficiente. 

A atribuição de muitos números de rede tem outra desvantagem que se torna evidente quando 
você pensa no roteamento. Lembre que a quantidade de informação de estado que é armazenada em 
um nó participando de um protocolo de roteamento é proporcional ao número de outros nós, e que 
o roteamento em uma inter-rede consiste em montar tabelas de encaminhamento que dizem a um 
roteador como alcançar diferentes redes. Assim, quanto maior o número de redes em uso, maiores são 


2É mais comum representar os endereços de rede sempre com quatro números, colocando 0s onde o endereço de rede 
efetivamente acaba (por exemplo, 128.96.0.0 em vez de simplesmente 128.96). Entretanto, nesta tradução conservamos a 
notação original do autor, que omite os Os finais.(N.T) 
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as tabelas de encaminhamento. Grandes tabelas de encaminhamento aumentam os custos dos rotea- 
dores, e fazer buscas nelas é potencialmente mais lento do que em tabelas menores para uma mesma 
tecnologia, de modo que elas degradam o desempenho do roteador. Isso oferece outra motivação para 
atribuir números de rede com cuidado. 

O uso de sub-redes é um primeiro passo para reduzir a quantidade total de números de rede que são 
atribuídos. A ideia é apanhar um único número de rede IP e alocar os endereços IP com esse número de rede 
a várias redes físicas, que agora são chamadas de sub-redes. Várias coisas precisam ser feitas para que isso 
funcione. Primeiro, as sub-redes devem estar próximas umas das outras. Isso porque, para um ponto distante 
na Internet, todas elas se parecerão com uma única rede, tendo apenas um número de rede entre elas. Isso 
significa que um roteador só poderá selecionar uma rota para alcançar qualquer uma das sub-redes, de modo 
que é melhor que todas elas estejam praticamente na mesma direção. Uma situação perfeita para usar as 
sub-redes é em um grande campus ou corporação, que possui muitas redes físicas. De fora do campus, tudo 
o que você precisa saber para alcançar qualquer sub-rede dentro do campus é onde o campus se conecta 
ao restante da Internet. Isso normalmente é um único ponto, de modo que uma entrada na sua tabela de 
encaminhamento será suficiente. Mesmo que existam vários pontos em que o campus é conectado ao res- 
tante da Internet, saber como chegar a um ponto na rede do campus ainda é um bom ponto de partida. 

O mecanismo pelo qual um único número de rede pode ser compartilhado entre várias redes envolve 
a configuração de todos os nós em cada sub-rede com uma máscara de sub-rede. Com endereços IP sim- 
ples, todos os hosts na mesma rede precisam ter o mesmo número de rede. A máscara de sub-rede nos 
permite introduzir um número de sub-rede; todos os hosts na mesma rede física terão o mesmo número 
de sub-rede, o que significa que os hosts podem estar em redes físicas diferentes, mas compartilhar um 
único número de rede. Esse conceito é ilustrado na Figura 3.20. 

O que a sub-rede significa para um host é que ele agora é configurado com um endereço IP e uma 
máscara de sub-rede para a sub-rede à qual está conectado. Por exemplo, o host H1 na Figura 3.21 é con- 
figurado com um endereço 128.96.34.15 e uma máscara de sub-rede 255.255.255.128. (Todos os hosts em 
determinada sub-rede são configurados com a mesma máscara; ou seja, existe exatamente uma máscara 
de sub-rede por sub-rede.) O operação de E bit a bit desses dois números define o número de sub-rede 
do host e de todos os outros hosts na mesma sub-rede. Nesse caso, 128.96.34.15 E 255.255.255.128 é igual 
a 128.96.34.0, de modo que esse é o número de sub-rede para a sub-rede mais ao alto na figura. 

Quando o host deseja enviar um pacote para um endereço IP a primeira coisa que ele faz é realizar 
uma operação de E bit a bit entre sua própria máscara de sub-rede e o endereço IP de destino. Se o 
resultado for igual ao número de sub-rede do host emissor, então ele sabe que o host de destino está 
na mesma sub-rede e o pacote pode ser entregue diretamente pela sub-rede. Se os resultados não 
forem iguais, o pacote precisa ser enviado a um roteador para ser encaminhado para outra sub-rede. 
Por exemplo, se H1 estiver enviando para H2, então H1 realiza a operação de E sobre a sua máscara de 
sub-rede (255.255.255.128) com o endereço para H2 (128.96.34.139), obtendo 128.96.34.128. Isso não 
corresponde ao número de sub-rede de H1 (128.96.34.0), de modo que H1 sabe que H2 está em uma 
sub-rede diferente. Como H1 não pode entregar o pacote a H2 diretamente pela sub-rede, ele envia o 
pacote para o seu roteador padrão R1. 

A tabela de encaminhamento de um roteador também muda ligeiramente quando introduzimos 
sub-redes. Lembre que anteriormente tínhamos uma tabela de endereços que consistia em entradas 
na forma (NúmeroRede, PróximoSalto). Para dar suporte às sub-redes, a tabela agora precisa manter 


Número de rede Número de host 


Endereço de classe B 


111111111111111111111111 — 00000000 


Máscara de sub-rede (255.255.255.0) 


ID de sub- 
rede 


Endereço de sub-rede FIGURA 3.20 Endereçamento de sub-rede. 


Número de rede ID de host 
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Tabela 3.7 Exemplo de tabela de encaminhamento com sub-redes para a Figura 3.21 





NúmeroSubRede MáscaraSubRede PróximoSalto 
128.96.34.0 255.255.255.128 Interface O 
128.96.34.128 255.255.255.128 Interface 1 
128.96.33.0 255.255.255.0 R2 


entradas na forma (NúmeroSubRede, MáscaraSubRede, PróximoSalto). Para encontrar a entrada certa 
na tabela, o roteador realiza o E do endereço de destino do pacote com a MáscaraSubRede para cada 
entrada de cada vez; se o resultado corresponder ao NúmeroSubRede da entrada, então esta é a entrada 
correta a usar, e ele encaminha o pacote para o roteador de próximo salto indicado. Na rede de exemplo 
da Figura 3.21, o roteador R1 teria as entradas mostradas na Tabela 3.7. 

Continuando com o exemplo de um datagrama de H1 sendo enviado para H2, R1 realizaria o E do 
endereço de H2 (128.96.34.139) com a máscara de sub-rede da primeira entrada (255.255.255.128) e 
compararia o resultado (128.96.34.128) com o número de rede para essa entrada (128.96.34.0). Como não 
há uma correspondência, ele prossegue para a próxima entrada. Desta vez, há uma correspondência, 
de modo que R1 entrega o datagrama a H2 usando a interface 1, que é a interface conectada à mesma 
rede que H2. 

Agora, podemos descrever o algoritmo de encaminhamento de datagrama da seguinte forma: 


D = endereço IP de destino 
para cada entrada <NúmeroSubRede, MáscaraSubRede, PróximoSaltoi> da tabela 
de encaminham o 


D1 = Máscar 








se Di = Númer 

se PróximoSalto é uma interface 

entregar o datagrama diretamente para o destino 

senão 

entregar o datagrama para o PróximoSalto (um roteador) 


Embora não seja mostrada neste exemplo, uma rota padrão normalmente seria incluída na tabela 
e usada se nenhuma correspondência explícita fosse encontrada. Observe, a propósito, que uma im- 
plementação simplista desse algoritmo — que calcule repetidamente a operação de E do endereço de 
destino com uma máscara de sub-rede, que pode não ser diferente a cada vez, seguida de uma busca 
linear da tabela — seria bastante ineficaz. 

Uma consequência importante das sub-redes é que diferentes partes da inter-rede veem o mundo de 
formas diferentes. De fora do nosso campus hipotético, os roteadores veem uma única rede. No exem- 
plo que utilizamos, os roteadores fora do campus veem a coleção de redes na Figura 3.21 como apenas 
a rede 128.96, e mantêm uma entrada em suas tabelas de encaminhamento para lhes informar como 


Máscara de sub-rede: 255.255.255.128 
Número de sub-rede: 128.96.34.0 


128.96.34.15 | 
pau 128.96.34.1 
= Br 
H1 C 
128.96.34.130 Máscara de sub-rede: 255.255.255.128 


Número de sub-rede: 128.96.34.139 


| 128.96.34.139 
128.96.34.129 

H3 o 

pu Rr 4 


128.96.33.1 


H2 
|128.96.33.14 


Máscara de sub-rede: 255.255.255.0 
Número de sub-rede: 128.96.33.0 FIGURA 3.21 Um exemplo de sub-rede. 
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alcançá-la. Os roteadores dentro do campus, porém, precisam ser capazes de rotear os pacotes para a 
sub-rede correta. Assim, nem todas as partes da inter-rede veem exatamente a mesma informação de 
roteamento. Este é um exemplo de agregação de informações de roteamento, que é fundamental para 
a expansão do sistema de roteamento. A próxima seção mostra como a agregação pode ser levada a 
outro nível. 


Endereçamento sem classes 

O uso de sub-redes tem um equivalente, às vezes chamada de super-rede, mas normalmente chamada 
de roteamento interdomínio sem classes, ou CIDR (Classless Interdomain Routing). O CIDR leva a 
ideia de sub-rede à sua conclusão lógica, basicamente deixando de lado por completo as classes de 
endereços. Por que usar apenas sub-redes não é suficiente? Basicamente, as sub-redes nos permitem 
dividir apenas um endereço com classes entre várias sub-redes, enquanto o CIDR nos permite agrupar 
vários endereços com classes em uma única “super-rede”. Isso resolve de uma forma ainda melhor a 
ineficiência do espaço de endereços observada anteriormente, e faz isso de um modo que evita que o 
sistema de roteamento seja sobrecarregado. 

Para ver como as questões de eficiência e escalabilidade do espaço de endereços do sistema de 
roteamento estão ligadas, considere o caso hipotético de uma empresa cuja rede tem 256 hosts. Isso é 
ligeiramente maior do que um endereço de classe C, e por isso você seria tentado a atribuir uma classe 
B a esta rede. Porém, usar um bloco do espaço de endereços que poderia endereçar 65.535 hosts para 
endereçar apenas 256 tem uma eficiência de apenas 256/65.535= 0,39%. Embora o uso de sub-redes 
possa nos ajudar a atribuir endereços com cuidado, isso não contorna o fato de que qualquer organi- 
zação com mais de 255 hosts, ou com uma expectativa de eventualmente atingir esse número, queira 
um endereço de classe B. 

A primeira forma como você poderia lidar com esse problema seria se recusar a dar um endereço 
de classe B a qualquer organização que o solicite, a menos que eles possam mostrar uma necessidade 
de algo próximo de 64K endereços, e em vez disso oferecer-lhes um número apropriado de endereços 
de classe C para cobrir o número de hosts esperado. Como agora estaríamos distribuindo o espaço de 
endereços em blocos de 256 endereços por vez, poderíamos combinar mais precisamente a quantidade 
de espaços de endereços consumida com o tamanho da organização. Para qualquer organização com 
pelo menos 256 hosts, podemos garantir uma utilização de endereços de pelo menos 50%, e normal- 
mente muito mais. 

Essa solução, porém, gera um problema que é pelo menos tão sério quanto esse: requisitos de armaze- 
namento excessivos nos roteadores. Se uma única organização tiver, digamos, 16 números de rede classe 
C atribuídos a ela, isso significa que cada roteador de backbone da Internet precisa de 16 entradas em 
sua tabela de roteamento para direcionar os pacotes para essa organização. Isso é verdade mesmo que 
o caminho para cada uma dessas redes seja o mesmo. Se tivéssemos atribuído um endereço de classe B 
à organização, a mesma informação de roteamento poderia ser armazenada em uma entrada da tabela. 
Porém, nossa eficiência de atribuição de endereços seria então de apenas 16x 255 / 65.536=6,2%. 

O CIDR, portanto, tenta equilibrar o desejo de minimizar o número de rotas que um roteador precisa 
saber e a necessidade de distribuir endereços de modo eficiente. Para fazer isso, o CIDR nos ajuda a 
agregar rotas. Ou seja, ele nos permite usar uma única entrada em uma tabela de encaminhamento 
para nos dizer como alcançar muitas redes diferentes. Conforme observamos anteriormente, ele 
faz isso quebrando os limites rígidos das classes de endereços. Para entender como isso funciona, 
considere nossa organização hipotética com 16 números de rede de classe C. Ao invés de entregar 16 
endereços aleatoriamente, podemos entregar um bloco de endereços contíguos de classe C. Suponha 
que atribuamos os números de rede de classe C de 192.4.16 a 192.4.31. Observe que os 20 bits mais 
significativos de todos os endereços nesse intervalo são iguais (11000000 00000100 0001). Assim, o que 
criamos efetivamente é um número de rede de 20 bits — algo que é melhor do que um número de rede 
de classe B e um número de classe C em termos do número de hosts que ele pode suportar. Em outras 
palavras, obtemos tanto uma alta eficiência ao distribuir endereços em blocos menores do que uma 
rede de classe B quanto um único prefixo de rede que pode ser usado em tabelas de encaminhamento. 
Observe que, para que esse esquema funcione, precisamos entregar blocos de endereços de classe C 
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Anuncia com CIDR. 
128.112.128/21 128.112.128/24 





128.112.129/24 


128.112.130/24 


128.112.135/24 


que compartilhem um prefixo em comum, o que significa que cada bloco precisa conter um número 
de redes de classe C que seja uma potência de dois. 

O CIDR requer um novo tipo de notação para representar números de rede, ou prefixos como são 
conhecidos, pois os prefixos podem ter qualquer tamanho. A convenção é colocar um /X após o prefixo, 
onde X é o tamanho do prefixo em bits. Assim, para o exemplo anterior, o prefixo de 20 bits para todas 
as redes de 192.4.16 a 192.4.31 é representado como 192.4.16/20. Em comparação, se quiséssemos re- 
presentar um número de rede de classe C, que tem 24 bits de comprimento, escreveríamos 192.4.16/24. 
Hoje, com CIDR sendo a norma, é mais comum escutar pessoas falando sobre prefixos “barra 24” do que 
redes de classe C. Observe que representar um endereço de rede dessa maneira é semelhante à técnica 
de (máscara, valor) usada nas sub-redes, desde que máscara consista em bits contíguos começando 
pelo bit mais significativo (o que, na prática, quase sempre acontece). 

A capacidade de agregar rotas na borda da rede, como vimos, é apenas o primeiro passo. Imagine 
uma rede de um provedor de serviços de Internet, cuja tarefa principal seja fornecer conectividade com 
a Internet para um grande número de empresas e campi (clientes). Se atribuirmos prefixos aos clientes 
de tal forma que muitas redes de clientes diferentes conectadas à rede do provedor compartilhem 
um prefixo de endereço em comum, mais curto, então poderemos ter uma agregação ainda maior de 
rotas. Considere o exemplo da Figura 3.22. Suponha que oito clientes atendidos pela rede do provedor 
tenham recebido, cada um, prefixos de rede adjacentes de 24 bits. Todos esses prefixos começam com 
os mesmos 21 bits. Como todos os clientes podem ser alcançados através da mesma rede de provedor, 
ela pode anunciar uma única rota para todos eles anunciando apenas o prefixo comum de 21 bits que 
eles compartilham. E ele pode fazer isso mesmo que nem todos os prefixos de 24 bits tenham sido 
entregues, desde que o provedor de fato tenha o direito de entregar esses prefixos a um cliente. Um 
modo de conseguir isso é atribuir uma parte do espaço de endereços ao provedor antecipadamente e 
depois permitir que o provedor da rede atribua endereços desse espaço para seus clientes, conforme a 
necessidade. Observe que, ao contrário desse exemplo simples, não é preciso que todos os prefixos de 
cliente tenham o mesmo tamanho. 


Revisão do encaminhamento IP 

Em toda a nossa discussão sobre encaminhamento IP até este ponto, consideramos que encontraríamos 
o número da rede em um pacote e depois buscaríamos esse número em uma tabela de encaminhamento. 
Porém, agora que apresentamos o CIDR, precisamos voltar a essa suposição. O uso do CIDR significa que 
os prefixos podem ter qualquer tamanho, de 2 a 32 bits. Além disso, às vezes é possível ter prefixos na 
tabela de encaminhamento que se “sobrepõem”, no sentido que alguns endereços podem corresponder 
a mais de um prefixo. Por exemplo, poderíamos encontrar 171.69 (um prefixo de 16 bits) e 171.69.10 (um 
prefixo de 24 bits) na tabela de encaminhamento de um mesmo roteador. Nesse caso, um pacote des- 
tinado a, digamos, 171.69.10.5 certamente corresponde aos dois prefixos. A regra, nesse caso, é baseada 
no princípio da “correspondência mais longa”, ou seja, o pacote é combinado com o prefixo mais longo, 
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que seria 171.69.10 neste exemplo. Por outro lado, um pacote destinado a 171.69.20.5 seria combinado 
com 171.69 e não com 171.69.10 e, na ausência de qualquer outra entrada na tabela de roteamento para 
a qual haja correspondência, 171.69 levaria à correspondência mais longa. 

A tarefa de encontrar de modo eficiente a correspondência mais longa entre um endereço IP e os 
prefixos de tamanho variável em uma tabela de encaminhamento tem sido um campo de pesquisa 
bastante frutífero nos últimos anos, e a seção de Leitura Adicional deste capítulo oferece algumas 
referências. O algoritmo mais bem conhecido utiliza uma técnica conhecida como árvore PATRICIA," 
que na realidade foi desenvolvida bem antes do CIDR. 


3.2.6 Tradução de endereços (ARP) 


Na seção anterior, falamos sobre como levar datagramas IP para a rede física correta, mas só abordamos 
brevemente a questão de como levar um datagrama a um host ou roteador em particular nessa rede. O 
problema principal é que os datagramas IP contêm endereços IP mas o hardware da interface física no 
host ou no roteador ao qual você deseja enviar o datagrama só entende o esquema de endereçamento 
dessa rede em particular. Assim, precisamos traduzir o endereço IP para um endereço em nível de enlace, 
que faça sentido nessa rede (por exemplo, um endereço Ethernet de 48 bits). Podemos, então, encapsular 
o datagrama IP dentro de um quadro que contém esse endereço em nível de enlace e enviá-lo ou para 
o destino final ou para um roteador que prometa encaminhar o datagrama para o destino final. 

Uma forma simples de mapear um endereço IP em um endereço físico da rede é codificar o endereço 
físico do host na parte de host do seu endereço IP Por exemplo, um host com endereço físico 00100001 
01001001 (que tem um valor decimal 33 no byte superior e 81 no byte inferior) poderia receber o 
endereço IP 128.96.33.81. Embora essa solução tenha sido usada em algumas redes, ela é limitada 
porque os endereços físicos da rede podem ter muito mais do que 16 bits de extensão neste exemplo; 
eles podem ter apenas 8 bits em uma rede classe C. Isso certamente não funcionará para endereços 
Ethernet de 48 bits. 

Uma solução mais geral seria que cada host mantivesse uma tabela de pares de endereços; ou seja, 
a tabela mapearia os endereços IP nos endereços físicos. Embora essa tabela pudesse ser gerenciada de 
modo central por um administrador do sistema e depois copiada para cada host na rede, uma técnica 
melhor seria que cada host descobrisse dinamicamente o seu conteúdo também usando a rede. Isso 
pode ser feito usando o protocolo de resolução de endereços, ou Address Resolution Protocol (ARP). 
O objetivo do ARP é permitir que cada host em uma rede construa uma tabela de mapeamentos entre 
os endereços IP e os endereços em nível de enlace. Como esses mapeamentos podem mudar com o 
tempo (por exemplo, porque uma placa Ethernet em um host apresenta defeito e é substituída por uma 
nova, com um novo endereço), as entradas são periodicamente verificadas e removidas. Isso acontece 
aproximadamente a cada 15 minutos. O conjunto de mapeamentos atualmente armazenados em um 
host é conhecido como cache ARP ou tabela ARP 

O ARP tira proveito do fato de que muitas tecnologias de rede em nível de enlace, como Ethernet, 
admitem broadcast. Se um host quiser enviar um datagrama IP a um host (ou roteador) que ele sabe 
que está na mesma rede (ou seja, o nó emissor e receptor têm o mesmo número de rede IP), ele primeiro 
procura por um mapeamento no seu cache. Se nenhum mapeamento for encontrado, ele precisa invocar 
o protocolo ARP na rede. Ele faz isso enviando por broadcast uma consulta ARP na rede. Essa consulta 
contém o endereço IP em questão (o endereço IP de destino). Cada host recebe a consulta e verifica se 
ela corresponde ao seu endereço IP Se este for o caso, o host envia uma mensagem de resposta contendo 
seu endereço da camada de enlace de volta à origem da consulta. O originador da consulta acrescenta 
a informação contida nessa resposta à sua tabela ARP 

A mensagem de consulta também inclui o endereço IP e o endereço da camada de enlace do host 
emissor. Assim, quando um host transmite uma mensagem de consulta por broadcast, cada nó na rede 
pode descobrir os endereços de enlace e IP do emissor, colocando essa informação em sua tabela ARP 


180 termo PATRICIA corresponde ao acrônimo “Practical Algorithm To Retrieve Information Coded In Alphanumeric”, 
ou “Algoritmo Prático Para Recuperar Informações Codificadas em Alfanumérico”. Esta árvore também é comumente 
denominada “árvore de prefixos”.( N.T.) 
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para mapeamento entre endereços 


Tipo de hardware = 1 TipoProtocolo = 0x0800 IP e endereços Ethernet. 


TamCab = 48 TampP = 32 Operação 
EndHardwareOrigem (bytes 0-3) 
EndHardwareOrigem (bytes 4-5) EndProtocoloOrigem (bytes 0-1) 
EndProtocoloOrigem (bytes 2-3) | EndHardwareDestino (bytes 0-1) 
EndHardwareDestino (bytes 2-5) 


EndProtocoloDestino (bytes 0-3) 


Porém, nem todo host acrescenta essa informação em sua tabela ARP Se o host já tiver uma entrada 
para esse host em sua tabela, ele “atualiza” essa entrada; ou seja, ele reinicia o período de tempo que 
dita quando a entrada será descartada. Se esse host for o destino da consulta, então ele acrescenta a 
informação sobre o emissor em sua tabela, mesmo que ela ainda não tivesse uma entrada para esse 
host. Isso acontece porque existe uma boa chance de que o host de origem esteja prestes a lhe enviar 
uma mensagem no nível de aplicação, e o host de destino eventualmente poderá ter que enviar uma 
resposta ou ACK de volta ao host de origem; ele precisará do endereço físico da origem para fazer isso. 
Se um host não for o destino e ainda não tiver uma entrada para a origem em sua tabela ARP então ele 
não acrescenta uma entrada para a origem. Isso porque não há motivos para acreditar que esse host 
precisará do endereço da origem no nível de enlace; não é preciso abarrotar sua tabela ARP com essa 
informação. 

A Figura 3.23 mostra o formato do pacote ARP para os mapeamentos de endereços IP para endereços 
Ethernet. Na realidade, o ARP pode ser usado para muitos outros tipos de mapeamentos — as principais 
diferenças estão nos tamanhos do endereço. Além dos endereços IP e da camada de enlace do emissor 
e o destino, o pacote contém: 


e Um campo TipoHardware, que especifica o tipo da rede física (por exemplo, Ethernet). 

e Um campo TipoProtocolo, que especifica o protocolo da camada mais alta (por exemplo, IP). 

e Campos TamCab (tamanho do endereço de “hardware”) e TamP (tamanho do endereço do 
“protocolo”), que especificam o tamanho do endereço da camada de enlace e o endereço do 
protocolo da camada superior, respectivamente. 

e Um campo Operação, que especifica se essa é uma solicitação ou uma resposta. 

e Os endereços de hardware (Ethernet) e protocolo (IP) de origem e destino. 


Observe que os resultados do processo de ARP podem ser acrescentados como uma coluna extra 
na tabela de encaminhamento, como aquela da Tabela 4.1. Assim, por exemplo, quando R2 precisa 
encaminhar um pacote para a rede 2, ele não apenas descobre que o próximo salto é R1, mas também 
encontra o endereço MAC a ser colocado no pacote para enviá-lo a R1. 


Até aqui, vimos os mecanismos básicos que o IP oferece para lidar com heterogeneidade e escalabilidade. 
Sobre a questão da heterogeneidade, o IP começa definindo um serviço de melhor esforço que faz 
suposições mínimas sobre as redes subjacentes; de forma mais notável, esse modelo de serviço é baseado 
em datagramas não confiáveis. O IP então, faz dois acréscimos importantes a esse ponto de partida: (1) um 
formato de pacote em comum (fragmentação /remontagem é o mecanismo que faz esse formato funcionar 


sobre redes com MTUSs diferentes) e (2) um espaço de endereços global para identificar todos os hosts (ARP 
é o mecanismo que faz esse espaço de endereços global funcionar sobre redes com diferentes esquemas 

de endereçamento físico). Sobre a questão da escalabilidade, o IP usa agregação hierárquica para reduzir 

a quantidade de informação necessária para encaminhar pacotes. Especificamente, os endereços IP são 
particionados em componentes de rede e de host, com pacotes primeiro roteados para a rede de destino e 
depois entregues ao host correto nessa rede. 
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3.2.7 Configuração de host (DHCP) 


Na Seção 2.6, observamos que os endereços Ethernet são configurados no adaptador de rede pelo fa- 
bricante e que esse processo é controlado de modo a garantir que esses endereços sejam globalmente 
exclusivos. Esta é certamente uma condição suficiente para garantir que qualquer coleção de hosts 
conectados a uma única Ethernet (incluindo uma LAN estendida) tenha endereços exclusivos. Além 
disso, a exclusividade é tudo o que pedimos dos endereços Ethernet. 

Os endereços IP por outro lado, não apenas precisam ser exclusivos em determinada inter-rede, 
mas devem também refletir a estrutura da inter-rede. Conforme observamos, eles são compostos por 
uma parte de rede e uma parte de host; e a parte de rede precisa ser a mesma para todos os hosts na 
mesma rede. Assim, não é possível que o endereço IP seja configurado uma vez em um host quando ele 
é fabricado, pois isso exigiria que o fabricante soubesse quais hosts acabariam ficando em quais redes, 
significando que um host, uma vez conectado a uma rede, nunca poderia passar para outra. Por esse 
motivo, os endereços IP precisam ser reconfiguráveis. 

Além de um endereço IP existem algumas outras informações que um host precisa ter antes que 
possa começar a enviar pacotes. A principal delas é o endereço de um roteador padrão — o local ao qual 
ele poderá enviar pacotes cujo endereço de destino não está na mesma rede do host emissor. 

A maioria dos sistemas operacionais oferece um modo de um administrador do sistema, ou mes- 
mo um usuário, configurar manualmente a informação de IP necessária por um host; porém, existem 
algumas desvantagens óbvias nessa configuração manual. Uma é que é simplesmente muito trabalhoso 
configurar todos os hosts de uma rede grande de forma direta, especialmente quando você considera 
que esses hosts não podem ser alcançados em uma rede até que estejam configurados. Ainda mais 
importante, o processo de configuração é muito passível de erros, pois é preciso garantir que cada host 
receba o número de rede correto e que dois hosts quaisquer não recebam o mesmo endereço IP Por 
esses motivos, são necessários métodos de configuração automatizados. O método principal usa um 
protocolo conhecido como Dynamic Host Configuration Protocol (DHCP). 

O DHCP conta com a existência de um servidor DHCP que é responsável por oferecer informações 
de configuração aos hosts. Há pelo menos um servidor DHCP para um domínio administrativo. No 
nível mais simples, o servidor DHCP pode funcionar apenas como um repositório centralizado para 
informações de configuração do host. Considere, por exemplo, o problema de administrar endereços na 
inter-rede de uma grande empresa. O DHCP evita que os administradores de rede tenham que caminhar 
até cada host na empresa com uma lista de endereços e mapa da rede em mãos para configurar cada host 
manualmente. Em vez disso, a informação de configuração para cada host poderia ser armazenada no 
servidor DHCP e recuperada automaticamente por cada host quando ele é inicializado ou conectado à 
rede. Porém, o administrador ainda escolheria o endereço que cada host deve receber; ele simplesmente 
o armazenaria no servidor. Nesse modelo, a informação de configuração para cada host é armazenada 
em uma tabela que é indexada por alguma forma de identificador exclusivo do cliente, normalmente o 
endereço de hardware (por exemplo, o endereço Ethernet do seu adaptador de rede). 

Um uso mais sofisticado do DHCP evita que o administrador da rede sequer tenha que atribuir 
endereços a hosts individuais. Nesse modelo, o servidor DHCP mantém um conjunto de endereços 
disponíveis que ele entrega aos hosts sob demanda. Isso reduz consideravelmente a quantidade de 
configuração que um administrador precisa realizar, pois agora só é preciso alocar um intervalo de 
endereços IP (todos com o mesmo número de rede) a cada rede. 

Como o objetivo do DHCP é reduzir a quantidade de configuração manual exigida para um host 
funcionar, essa finalidade não seria exatamente atingida se cada host tivesse que ser configurado com 
o endereço de um servidor DHCP Assim, o primeiro problema enfrentado pelo DHCP é o de descoberta 
do servidor. 

Para entrar em contato com um servidor DHCP um host recém-inicializado ou conectado envia 
uma mensagem DHCPDISCOVER a um endereço IP especial (255.255.255.255), que é um endereço de 
broadcast IP Isso significa que ela será recebida por todos os hosts e roteadores nessa rede. (Os roteadores 
não encaminham esses pacotes para outras redes, prevenindo que o broadcast seja encaminhado para a 
Internet inteira.) No caso mais simples, um desses nós é o servidor DHCP para a rede. O servidor, então, 
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responderia ao host que gerou a mensagem de descoberta (todos os outros nós a ignorariam). Porém, 
não é realmente desejável exigir que haja um servidor DHCP em cada rede, pois isso ainda cria um 
número potencialmente grande de servidores que precisam ser configurados correta e consistentemente. 
Assim, o DHCP usa o conceito de um agente de repasse. Há pelo menos um agente de repasse em cada 
rede, e este é configurado com apenas uma informação: o endereço IP do servidor DHCP Quando um 
agente de repasse recebe uma mensagem DHCPDISCOVER, ele a envia por unicast ao servidor DHCP e 
espera a resposta, que será então enviada de volta ao cliente solicitante. O processo de repasse de uma 
mensagem de um host para um servidor DHCP remoto é mostrado na Figura 3.24. 

A Figura 3.25 mostra o formato de uma mensagem DHCP A mensagem é enviada de fato usando 
um protocolo chamado User Datagram Protocol (UDP), que opera sobre o IP O UDP é discutido em 
detalhes no próximo capítulo, mas a única coisa interessante que ele faz nesse contexto é oferecer uma 
chave de demultiplexação que diz: “este é um pacote DHCP”. 

O DHCP é derivado de um protocolo mais antigo, chamado BOOTP e alguns dos campos de pacote, 
assim, não são estritamente relevantes à configuração do host. Ao tentar obter informações de configura- 
ção, o cliente coloca seu endereço de hardware (por exemplo, seu endereço Ethernet) no campo chaddr 
(client hardware address ou endereço de hardware do cliente) O servidor DHCP responde preenchendo 
o campo yiaddr (“your” IP address ou “seu” endereço IP) e enviando-o ao cliente. Outras informações, 
como o roteador padrão a ser usado por esse cliente, podem ser incluídas no campo opções. 

No caso em que o DHCP atribui endereços IP dinamicamente aos hosts, é claro que os hosts não 
podem manter endereços indefinidamente, pois isso faria com que o servidor esgotasse seu conjunto 
de endereços. Ao mesmo tempo, não se pode depender de um host para retornar seu endereço, pois 
ele poderia apresentar defeito, ser desconectado da rede ou ser desligado. Assim, o DHCP permite 


Unicast para o servidor 
ci 


— Repasse "Outras redes 
DHCP 
Servidor DHCP 
Broadcast 
7 : FIGURA 3.24 Um agente de repasse DHCP recebe uma 
a mensagem de broadcast DHCPDISCOVER de um host e 
Host envia um DHCPDISCOVER unicast para o servidor DHCP. 
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opções FIGURA 3.25 Formato de pacote DHCP. 
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que os endereços sejam alocados por algum período de tempo. Quando o tempo de alocação expira, 
o servidor fica livre para retornar esse endereço ao seu conjunto. Um host com um endereço alocado 
precisa renovar a alocação periodicamente se, de fato, ainda estiver conectado à rede e funcionando 
corretamente. 


O DHCP ilustra um aspecto importante da escalabilidade: a escalabilidade de gerenciamento da rede. 
Embora as discussões sobre escalabilidade frequentemente se concentrem em evitar que a quantidade 
de informações de estado nos dispositivos de rede cresça muito rapidamente, é importante atentar ao 
crescimento da complexidade do gerenciamento da rede. Ao permitir que os gerentes de rede configurem 


uma faixa de endereços IP por rede em vez de um endereço IP por host, o DHCP melhora a capacidade de 
gerenciamento de uma rede. 

Observe que o DHCP também pode introduzir alguma complexidade adicional ao gerenciamento de rede, 
pois ele torna a ligação entre os hosts físicos e os endereços IP muito mais dinâmica. Isso pode dificulta a 
tarefa do gerente de rede se, por exemplo, for necessário localizar um host que esteja apresentando defeito. 





3.2.8 Relatório de erros (ICMP) 


O próximo problema é como a Internet trata dos erros. Embora o IP esteja perfeitamente disposto a des- 
cartar datagramas quando as coisas ficam difíceis — por exemplo, quando um roteador não sabe como 
encaminhar o datagrama ou quando um fragmento de um datagrama deixa de chegar ao destino -, ele 
não necessariamente falha silenciosamente. O IP está sempre configurado com um protocolo que o 
acompanha, conhecido como protocolo de mensagens de controle da Internet ICMP - Internet Control 
Message Protocol), que define uma coleção de mensagens de erro que são enviadas de volta ao host de 
origem sempre que um roteador ou host é incapaz de processar um datagrama IP com sucesso. Por 
exemplo, o ICMP define mensagens de erro indicando que o host de destino está inalcançável (talvez 
devido a uma falha de enlace), que o processo de remontagem falhou, que o TTL chegou a 0, que a soma 
de verificação do cabeçalho IP falhou, e assim por diante. 

O ICMP também define algumas mensagens de controle que um roteador pode enviar de volta a 
um host de origem. Uma das mensagens de controle mais úteis, chamada ICMP-Redirect (redireciona- 
mento ICMP), informa o host de origem que existe uma rota melhor para o destino. ICM-Redirects são 
usados na seguinte situação. Suponha que um host esteja conectado a uma rede com dois roteadores 
conectados, chamados R1 e R2, onde o host usa R1 como seu roteador padrão. Se R1 receber um data- 
grama do host de forma que, com base em sua tabela de encaminhamento, ele sabe que R2 teria sido 
uma escolha melhor para este endereço de destino em particular, ele envia um ICMP-Redirect de volta 
ao host, instruindo-o a usar R2 para todos os datagramas futuros endereçados a esse destino. O host, 
então, acrescenta essa nova rota à sua tabela de encaminhamento. 

O ICMP também fornece a base para duas ferramentas de depuração muito usadas, ping e traceroute. 
Aferramenta ping usa mensagens de eco ICMP para determinar se um nó pode ser alcançado e está ativo. 
O traceroute usa uma técnica ligeiramente não intuitiva para determinar o conjunto de roteadores ao 
longo do seu caminho até um destino, que é o tópico para um dos exercícios ao final deste capítulo. 


3.2.9 Redes virtuais e túneis 


Concluímos nossa introdução ao IP considerando uma questão que você pode não ter antecipado, 
mas que está se tornando cada vez mais importante. Nossa discussão até este ponto foi focada em 
tornar possível que os nós em diferentes redes se comuniquem entre si de uma forma irrestrita. Esse 
normalmente é o objetivo na Internet — todos querem poder enviar e-mail para todos, e o criador de 
um novo site Web deseja atingir a maior audiência possível. Porém, existem muitas situações onde uma 
conectividade mais controlada é necessária. Um exemplo importante dessa situação é a rede privada 
virtual (VPN - Virtual Private Network). 

O termo VPN é utilizado em demasia e as definições variam, mas intuitivamente podemos definir uma 
VPN considerando primeiro a ideia de uma rede privada. As corporações com muitas sedes normalmente 
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z FIGURA 3.26 Um exemplo de redes privadas virtuais: (a) 
Enlaces físicos duas redes privadas separadas; (b) duas redes privadas 
virtuais compartilhando switches comuns. 
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montam redes privadas alugando linhas de transmissão das companhias telefônicas e usando essas li- 
nhas para interconectar as sedes. Nessa rede, a comunicação é restringida, de modo a ocorrer somente 
entre as sedes dessa corporação, o que normalmente é desejável por motivos de segurança. Para tornar 
a rede privada virtual, as linhas de transmissão alugadas — que não são compartilhadas com quaisquer 
outras corporações — seriam substituídas por algum tipo de rede compartilhada. Um circuito virtual (VC 
— Virtual Circuit) é um substituto bastante razoável para uma linha alugada, pois oferece uma conexão 
lógica ponto a ponto entre as sedes da corporação. Por exemplo, se a corporação X tem um VC da sede 
A à sede B, então ela claramente pode enviar pacotes entre A e B. Mas não existe como a corporação Y 
entregar seus pacotes à sede B sem primeiro estabelecer seu próprio circuito virtual com a sede B, e o 
estabelecimento desse VC pode ser prevenida administrativamente, impedindo assim a conectividade 
indesejada entre a corporação X e a corporação Y. 

A Figura 3.26(a) mostra duas redes privadas para duas corporações separadas. Na Figura 3.26(b), 
ambas são migradas para uma rede de circuitos virtuais. A conectividade limitada de uma rede privada 
real é mantida, mas como as redes privadas agora compartilham as mesmas instalações de transmissão 
e switches, dizemos que duas redes privadas virtuais foram criadas. 

Na Figura 3.26, uma rede de circuitos virtuais (usando Frame Relay ou ATM, por exemplo) é usada 
para fornecer a conectividade controlada entre diferentes locais. Também é possível oferecer uma 
função semelhante usando uma rede IP - uma inter-rede — para fornecer conectividade. Porém, não 
podemos simplesmente conectar as sedes das diversas corporações usando uma única inter-rede, pois 
isso ofereceria conectividade entre a corporação X e a corporação Y, o que queremos evitar. Para resolver 
esse problema, precisamos introduzir um novo conceito, o túnel IP. 

Podemos pensar em um túnel IP como um enlace ponto a ponto virtual entre um par de nós que, na 
realidade, são separados por um número qualquer de redes. O enlace virtual é criado dentro do roteador 
na entrada do túnel fornecendo-lhe o endereço IP do roteador no final do túnel. Sempre que o roteador 
na entrada do túnel deseja enviar um pacote por esse enlace virtual, ele encapsula o pacote dentro de 
um datagrama IP O endereço de destino no cabeçalho IP é o endereço do roteador na outra ponta do 
túnel, enquanto o endereço de origem é o do roteador que faz o encapsulamento. 

Na tabela de encaminhamento do roteador na entrada do túnel, esse enlace virtual se parece muito 
com um enlace normal. Considere, por exemplo, a rede da Figura 3.27. Um túnel foi configurado de 
R1 para R2 e recebeu um número de interface virtual 0. A tabela de encaminhamento em R1 poderia, 
portanto, se parecer com a Tabela 3.8. 

RF1 tem duas interfaces físicas. A interface 0 se conecta à rede 1; a interface 1 se conecta a uma 
inter-rede grande e, portanto, é a interface padrão para todo o tráfego que não corresponde a algo mais 
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R1 R2 
Rede 1 Ea Inter-rede 25 Rede 2 
| 18.5.0.1 
Cabeçalho IP, Cabeçalho IP, Cabeçalho IP, 
Destino = 2.x Destino = 18.5.0.1 Destino = 2.x 
Da — cad 
Cabeçalho IP, 
Payload IP Destino = 2.x Payload IP 
Payload IP 


FIGURA 3.27 Um túnel através de uma inter-rede. O endereço de R2 é 18.5.0.1, que pode ser alcançado a partir de R1 pela inter-rede. 


Tabela 3.8 Tabela de encaminhamento para o Roteador R1 na Figura 3.27 





NúmeroRede PróximoSalto 

1 Interface O 

2 Interface virtual O 
Padrão Interface 1 


específico na tabela de encaminhamento. Além disso, R1 tem uma interface virtual, que é a interface 
para o túnel. Suponha que R1 receba um pacote da rede 1 destinado a um endereço na rede 2. A tabela 
de encaminhamento diz que esse pacote deve ser enviado para a interface virtual 0. Para enviar um 
pacote por essa interface, o roteador apanha o pacote, acrescenta um cabeçalho IP endereçado para R2 
e depois dá prossegue com o encaminhamento do pacote como se ele tivesse acabado de ser recebido. 
O endereço de R2 é 18.5.0.1; como o número de rede desse endereço é 18, e não 1 ou 2, um pacote des- 
tinado para R2 será encaminhado pela interface padrão para a inter-rede. 

Quando o pacote sai de R1, o restante do mundo o enxerga como um pacote IP normal destinado 
a R2, e é encaminhado de acordo. Todos os roteadores na inter-rede o encaminham usando meios 
normais, até que ele chegue a R2. Quando R2 recebe o pacote, ele descobre que o pacote transporta 
seu próprio endereço, de modo que ele remove o cabeçalho IP e examina o payload do pacote. O que 
ele encontra é um pacote IP interno, cujo endereço de destino está na rede 2. R2 agora processa esse 
pacote como qualquer outro pacote IP que ele recebe. Como R2 está conectado diretamente à rede 2, 
ele encaminha o pacote para essa rede. A Figura 3.27 mostra a mudança no encapsulamento do pacote 
à medida que ele se move pela rede. 

Embora R2 esteja atuando como extremidade do túnel, não há nada que o impeça de realizar as 
funções normais de um roteador. Por exemplo, ele poderia receber alguns pacotes que não estão em 
um túnel, mas que são endereçados para redes que ele sabe como alcançar, e os encaminharia de forma 
normal. 

Você pode estar perguntando por que alguém iria querer ter o trabalho de criar um túnel e mudar o 
encapsulamento de um pacote enquanto ele atravessa uma inter-rede. Um motivo é a segurança, que 
discutiremos com mais detalhes no Capítulo 8. Combinada com técnicas de criptografia, um túnel pode 
se tornar um tipo de enlace muito particular sobre uma rede pública. Outro motivo pode ser que R1 e R2 
tenham algumas capacidades que não estão amplamente disponíveis nas redes intermediárias, como 
o roteamento multicast. Ao conectar esses roteadores por meio de um túnel, podemos montar uma 
rede virtual em que todos os roteadores com essa capacidade parecem estar diretamente conectados. 
De fato, é assim que o MBone (multicast backbone) é construído, conforme veremos na Seção 4.2. Um 
terceiro motivo para montar túneis é para transportar pacotes dos protocolos diferentes do IP por uma 
rede IP Contanto que os roteadores em qualquer um dos extremos do túnel saibam como lidar com 
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esses outros protocolos, o túnel IP para eles tem a aparência de um enlace ponto a ponto sobre o qual 
eles podem enviar pacotes não IP Os túneis também oferecem um mecanismo pelo qual podemos 
forçar um pacote a ser entregue a um local em particular, mesmo que seu cabeçalho original — aquele 
que é encapsulado dentro do cabeçalho do túnel - possa sugerir que ele deva ir para algum outro lugar. 
Veremos uma aplicação disso quando considerarmos os hosts móveis na Seção 4.4.2. Assim, vemos que o 
tunelamento é uma técnica muito poderosa e geral para a criação de enlaces virtuais por inter-redes. 

O tunelamento tem suas desvantagens. Uma é que ele aumenta o tamanho dos pacotes; isso poderia 
representar um desperdício significativo da largura de banda para pacotes curtos. Pacotes maiores 
poderiam estar sujeitos a fragmentação, que tem seu próprio conjunto de desvantagens. Também pode 
haver implicações no desempenho para os roteadores em qualquer extremidade do túnel, pois eles 
precisam realizar mais trabalho do que o encaminhamento normal enquanto acrescentam e removem 
o cabeçalho do túnel. Finalmente, existe o custo de gerenciamento para a entidade administrativa que é 
responsável por estabelecer os túneis e garantir que eles sejam tratados corretamente pelos protocolos 
de roteamento. 


3.3 Roteamento 


Até aqui neste capítulo, consideramos que os switches e roteadores possuem conhecimento suficiente 
da topologia da rede para que possam escolher a porta certa pela qual cada pacote deverá ser enviado. 
No caso de circuitos virtuais, o roteamento é um problema somente para o pacote de solicitação de 
conexão; todos os pacotes seguintes seguem o mesmo caminho da solicitação. Em redes de datagramas, 
incluindo redes IP o roteamento é um problema para cada pacote. De qualquer forma, um switch ou 
roteador precisa ser capaz de examinar um endereço de destino e então determinar qual das portas 
de saída é a melhor escolha para levar um pacote para esse endereço. Como vimos na Seção 3.1.1, o 
switch toma essa decisão consultando uma tabela de encaminhamento. O problema fundamental do 
roteamento é como os switches e roteadores adquirem a informação que é colocada em suas tabelas 
de encaminhamento. 


Reforçamos uma distinção importante, que é constantemente negligenciada, entre o encaminhamento 
e o roteamento. O encaminhamento consiste em tomar um pacote, examinar seu endereço de destino, 
consultar uma tabela e enviar o pacote em uma direção determinada por essa tabela. Vimos vários exemplos 


de encaminhamento na seção anterior. O roteamento é o processo pelo qual as tabelas de encaminhamento 
são montadas. Também notamos que o encaminhamento é um processo relativamente simples e bem 
definido, realizado localmente em um nó, enquanto o roteamento depende de algoritmos distribuídos 
complexos, que continuaram a evoluir ao longo da história das redes. 





Embora os termos tabela de encaminhamento e tabela de roteamento às vezes sejam usados para 
indicar a mesma coisa, faremos uma distinção entre eles aqui. A tabela de encaminhamento é usada 
quando um pacote está sendo encaminhado e, portanto, precisa conter informações suficientes pra rea- 
lizar a função de encaminhamento. Isso significa que uma linha na tabela de encaminhamento contém 
o mapeamento de um prefixo de rede para uma interface de saída e alguma informação de MAC, como 
o endereço Ethernet do próximo salto. A tabela de roteamento, por outro lado, é a tabela que é montada 
pelos algoritmos de roteamento como um precursor para a montagem da tabela de encaminhamento. 
Ela geralmente contém mapeamentos de prefixos da rede para os próximos saltos. Ela também pode 
conter informações sobre como essa informação foi descoberta, de modo que o roteador possa decidir 
quando ele deve descartar alguma informação. 

Se a tabela de roteamento e a tabela de encaminhamento são de fato estruturas de dados separadas 
é uma escolha que depende da implementação, mas existem vários motivos para mantê-las separadas. 
Por exemplo, a tabela de encaminhamento precisa ser estruturada para otimizar o processo de consulta 
de um endereço quando se quer encaminhar um pacote, enquanto a tabela de roteamento precisa ser 
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Tabela 3.9 Linhas de exemplo de tabelas de (a) roteamento e (b) encaminhamento 














(a) 

Prefixo/Tamanho Próximo salto 

18/8 171.69.245.10 

(b) 

Prefixo/Tamanho Interface Endereço MAC 
18/8 ifo 8:0:2b:e4:b:1:2 


otimizada para o processo de calcular mudanças na topologia. Em muitos casos, a tabela de encami- 
nhamento pode ainda ser implementada no hardware especializado, enquanto isso raramente ou 
nunca é feito para a tabela de roteamento. A Tabela 3.9 oferece um exemplo de uma linha de cada tipo 
de tabela. Nesse caso, a tabela de roteamento nos diz que o prefixo de rede 18/8 deve ser alcançado por 
um roteador de próximo salto cujo endereço IP é 171.69.245.10, enquanto a tabela de encaminhamento 
contém a informação sobre exatamente como encaminhar um pacote para esse próximo salto: envie-o 
pela interface número 0 com um endereço de MAC 8:0:2b:e4:b:1:2. Observe que a última informação é 
fornecida pelo Address Resolution Protocol (ARP). 

Antes de entrarmos nos detalhes do roteamento, precisamos recordar sobre a principal pergunta 
que deve ser feita antes de tentarmos construir um mecanismo para a Internet: “Essa solução é es- 
calável?”. A resposta para os algoritmos e protocolos descritos nesta seção é “não muito”. Eles são 
projetados para redes de tamanho relativamente modesto — até algumas centenas de nós, na prática. 
Porém, as soluções que descrevemos servem como um bloco construtivo para uma infraestrutura de 
roteamento hierárquica usada na Internet hoje. Especificamente, os protocolos descritos nesta seção 
são coletivamente conhecidos como protocolos de roteamento intradomínio, ou protocolos de gateway 
interior (IGPs — Interior Gateway Protocols). Para entender esses termos, precisamos definir um domínio 
de roteamento. Uma boa definição de trabalho é uma inter-rede em que todos os roteadores estão sob 
o mesmo controle administrativo (por exemplo, um único campus universitário ou a rede de um único 
provedor de serviços de Internet). A relevância dessa definição se tornará clara no próximo capítulo, 
quando examinarmos os protocolos de roteamento interdomínio. Por enquanto, o mais importante 
a lembrar é que estamos considerando o problema de roteamento no contexto de redes pequenas a 
médias, e não para uma rede do tamanho da Internet. 


3.3.1 Rede como um grafo 


O roteamento, basicamente, é um problema de teoria dos grafos. A Figura 3.28 mostra um grafo re- 
presentando uma rede. Os nós do grafo, rotulados de A até F podem ser hosts, switches, roteadores e 
redes. Para nossa discussão inicial, vamos nos concentrar no caso onde os nós são roteadores. As arestas 
do grafo correspondem aos enlaces da rede. Cada aresta tem um custo associado, que fornece alguma 
indicação da necessidade de enviar tráfego por esse enlace. Uma discussão de como os custos da aresta 
são atribuídos é fornecida na Seção 3.3.4.1: 





FIGURA 3.28 Rede representada como um grafo. 


Nas redes (grafos) de exemplo usados neste capítulo, usamos as arestas em uma única direção e atribuímos a cada aresta 
um único custo. Na realidade, isso é uma ligeira simplificação. É mais preciso fazer arestas direcionadas, o que normalmente 
significa que haveria um par de arestas entre cada nó — uma fluindo em cada direção e cada uma com seu próprio custo de 
aresta. 
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O problema básico do roteamento é encontrar o caminho de menor custo entre dois nós quaisquer, 
onde o custo de um caminho é igual à soma dos custos de todas as arestas que compõem o caminho. Para 
uma rede simples, como aquela na Figura 3.28, você poderia simplesmente calcular todos os caminhos 
mais curtos e carregá-los em alguma unidade de armazenamento não volátil em cada nó. Essa técnica 
estática tem várias desvantagens: 


e Ela não lida com falhas de nó ou enlace. 

e Ela não considera o acréscimo de novos nós ou enlaces. 

e Ela implica que os custos não podem mudar, embora possamos razoavelmente querer ter custos 
de enlace mudando com o tempo (por exemplo, atribuindo um custo alto a um enlace bastante 
carregado). 


Por esses motivos, o roteamento é conseguido na maioria das redes práticas executando protocolos de 
roteamento entre os nós. Esses protocolos oferecem um modo distribuído e dinâmico para solucionar o 
problema de encontrar o caminho de menor custo na presença de falhas de enlace e nó e custos de aresta 
mutáveis. Observe a palavra distribuído na sentença anterior; é difícil tornar soluções centralizadas escalá- 
veis, de modo que todos os protocolos de roteamento mais usados utilizam algoritmos distribuídos.!5 

A natureza distribuída dos algoritmos de roteamento é um dos principais motivos pelos quais esse 
tem sido um campo de pesquisa e desenvolvimento tão rico — existem muitos desafios para fazer com 
que os algoritmos distribuídos funcionem bem. Por exemplo, os algoritmos distribuídos abrem a pos- 
sibilidade de que dois roteadores, em algum instante, tenham diferentes ideias sobre o caminho mais 
curto para algum destino. De fato, cada um deles pode pensar que o outro está mais próximo do destino 
e decidir enviar os pacotes um para o outro. Claramente, esses pacotes ficarão presos em um ciclo até 
que a discrepância entre os dois roteadores seja resolvida, e seria bom resolver isso o mais cedo possível. 
Este é apenas um exemplo do tipo de problema que os protocolos de roteamento precisam enfrentar. 

Para começar nossa análise, vamos supor que os custos da aresta na rede sejam conhecidos. Vamos 
examinar as duas principais classes de protocolos de roteamento: vetor de distâncias e estado do enlace. Na 
Seção 3.3.4, vamos retornar ao problema de calcular os custos da aresta de uma maneira significativa. 


3.3.2 Vetor de distâncias (RIP) a 


RIP 
A ideia por trás do algoritmo de vetor de distância é sugerido por seu nome.!º Cada nó constrói uma 
sequência unidimensional (um vetor) contendo as “distâncias” (custos) para todos os outros nós e dis- 
tribui esse vetor aos seus vizinhos imediatos. A suposição inicial para o roteamento por vetor de distância 
é que cada nó conhece o custo do enlace para cada um dos vizinhos aos quais ele está diretamente 
conectado. Esses custos podem ser fornecidos quando o roteador é configurado por um gerente de 
rede. Um enlace inativo recebe um custo infinito. 
Para ver como um algoritmo de roteamento por vetor de distâncias funciona, é mais fácil considerar 
um exemplo como aquele representado na Figura 3.29. Nesse exemplo, o custo de cada enlace é definido 
como 1, de modo que um caminho com menor custo é simplesmente aquele com o mínimo de saltos. 





(6) FIGURA 3.29 Roteamento por vetor de distância: uma rede de exemplo. 


15Porém, essa suposição amplamente adotada tem sido reexaminada nos últimos anos - veja a seção de Leitura Adicional. 
160 outro nome comum para essa classe de algoritmo é Bellman-Ford, que são os nomes de seus inventores. 
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(Como todas as arestas têm o mesmo custo, não mostramos os custos no grafo.) Podemos representar 
o conhecimento de cada nó sobre as distâncias para todos os outros nós como uma tabela, do tipo da 
Tabela 3.10. Observe que cada nó sabe apenas a informação mostrada em uma linha da tabela (aquela 
que contém seu nome na coluna da esquerda). A visão global que apresentamos aqui não está disponível 
a qualquer ponto isolado na rede. 

Podemos considerar cada linha da Tabela 3.10 como uma lista de distâncias de um nó para todos 
os outros nós, representando aquilo em que esse nó acredita atualmente. Primeiro, cada nó define 
um custo de 1 para os vizinhos aos quais está conectado diretamente e de œ para todos os outros nós. 
Assim, A acredita inicialmente que pode alcançar B em um salto e que D é inalcançável. A tabela de 
roteamento armazenada em A reflete esse conjunto de crenças e inclui o nome do próximo salto que 
A usaria para alcançar qualquer nó inalcançável. Inicialmente, então, a tabela de roteamento de A se 
pareceria com a Tabela 3.11. 

O próximo passo no roteamento por vetor de distâncias é que cada nó envie uma mensagem aos seus 
vizinhos aos quais está diretamente conectado contendo sua lista pessoal de distâncias. Por exemplo, 
o nó F diz ao nó A que ele pode alcançar o nó G a um custo de 1; A também sabe que pode alcançar F 
a um custo de 1, de modo que ele soma esses custos para obter o custo para alcançar G por meio de E 
Esse custo total de 2 é menor que o custo atual de infinito, de modo que A registra que pode alcançar G 
a um custo de 2 passando por E De modo semelhante, A descobre via C que D pode ser alcançado por 
C a um custo de 1; ele soma isso ao custo de alcançar C (1) e decide que D pode ser alcançado via C a 
um custo de 2, que é melhor do que o antigo custo de infinito. Ao mesmo tempo, A descobre de C que 
B pode ser alcançado por C a um custo de 1, de modo que conclui que o custo para alcançar B via C é 
2. Como isso é pior do que o custo atual de alcançar B (1), essa nova informação é ignorada. 

Neste ponto, A pode atualizar sua tabela de roteamento com os custos e os próximos saltos para 
todos os nós na rede. O resultado aparece na Tabela 3.12. 

Na ausência de quaisquer mudanças de topologia, são necessárias apenas algumas trocas de in- 
formação entre os vizinhos antes que cada nó tenha uma tabela de roteamento completa. O processo 
de levar informações de roteamento consistentes para todos os nós é chamado de convergência. A 
Tabela 3.13 mostra a etapa final dos custos de cada nó para todos os outros nós quando o roteamento 
tiver convergido. É preciso enfatizar que não existe qualquer nó na rede que tenha toda a informação 


Tabela 3.10 Distâncias iniciais armazenadas em cada nó (visão global) 


Informação Distância para alcançar o nó 
armazenada A B c D E 
no nó 
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Tabela 3.11 Tabela de roteamento inicial no nó A 


Destino Custo PróximosSalto 
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Tabela 3.12 Tabela de roteamento final no nó A 





Destino Custo PróximosSalto 
B 1 B 
C 1 C 
D 2 C 
E 1 E 
F 1 F 
G 2 F 


Tabela 3.13 Distâncias finais armazenadas em cada nó (visão global) 


Informação Distância para alcançar o nó 








armazenada A B c D E F G 
no nó 

A 0 1 1 2 1 1 2 
B 1 0 1 2 2 2 3 
C 1 1 0 1 2 2 2 
D 2 2 1 (0) 3 2 1 

E 1 2 2 3 (0) 2 3 
F 1 2 2 2 2 0 1 

G 2 3 2 1 3 1 0 


nessa tabela — cada nó sabe apenas o conteúdo de sua própria tabela de roteamento. A beleza de um 
algoritmo distribuído como este é que ele permite que todos os nós alcancem uma visão consistente 
da rede na ausência de qualquer autoridade centralizada. 

Existem alguns detalhes a serem descritos antes que finalizar nossa discussão sobre roteamento por 
vetor de distâncias. Primeiro, observamos que existem duas circunstâncias diferentes sob as quais deter- 
minado nó decide enviar uma atualização de roteamento aos seus vizinhos. Uma dessas circunstâncias 
é a atualização periódica. Nesse caso, cada nó envia automaticamente uma mensagem de atualização 
com alguma frequência, mesmo que nada tenha mudado. Isso faz com que outros nós saibam que esse 
nó ainda está funcionando. Isso também garante que eles continuem obtendo informações que podem 
precisar se suas rotas atuais se tornarem inviáveis. A frequência dessas atualizações periódicas varia de 
um protocolo para outro, mas isso normalmente é da ordem de vários segundos a vários minutos. O 
segundo mecanismo, às vezes chamados de atualização disparada, acontece sempre que um nó observa 
uma falha de enlace ou recebe uma atualização de um de seus vizinhos, fazendo com que ele mude 
uma das rotas em sua tabela de roteamento. Sempre que a tabela de roteamento de um nó muda, ele 
envia uma atualização aos seus vizinhos, o que pode levar a uma mudança em suas tabelas, fazendo 
com que eles enviem uma atualização aos seus vizinhos. 

Agora, considere o que acontece quando um enlace ou nó falha. Os nós que percebem isto primeiro 
enviam novas listas de distâncias para seus vizinhos, e normalmente o sistema se estabiliza muito 
rapidamente em um novo estado. Quanto à questão de como um nó detecta uma falha, existem algumas 
respostas diferentes. Em uma abordagem, um nó testa continuamente o enlace até outro nó, enviando 
um pacote de controle e verificando se ele recebe uma confirmação de sua recepção. Em outra abor- 
dagem, um nó determina que o enlace (ou o nó na outra ponta do enlace) está inativo se não receber a 
atualização de roteamento periódico esperada durante os últimos ciclos de atualização. 

Para entender o que acontece quando um nó detecta uma falha de enlace, considere o que acontece 
quando F detecta que seu enlace com G falhou. Primeiro, F define sua nova distância para G como in- 
finito e passa essa informação adiante para A. Como A sabe que seu caminho de 2 saltos para G passa 
por E A também definiria sua distância para G como infinito. Porém, com a próxima atualização de C, A 
descobriria que C tem um caminho de 2 saltos para G. Assim, A saberia que pode alcançar G em 3 saltos 
através de C, o que é menor que infinito, e portanto A atualizaria sua tabela de modo correspondente. 
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Quando ele anuncia isso a E o nó F descobre que pode alcançar G a um custo de 4 através de A, que é 
menor que infinito, e o sistema novamente se tornaria estável. 

Infelizmente, circunstâncias ligeiramente diferentes podem impedir que a rede se estabilize. Supo- 
nha, por exemplo, que o enlace de A para E seja rompido. Na próxima rodada de atualizações, A anuncia 
uma distância de infinito para E, mas B e C anunciam uma distância de 2 para E. Dependendo do ins- 
tante exato dos eventos, poderia acontecer o seguinte. O nó B, ao escutar que E pode ser alcançado em 
2 saltos através de C, conclui que pode alcançar E em 3 saltos e anuncia isso para A; o nó A conclui que 
pode alcançar E em 4 saltos e anuncia isso para C; o nó C conclui que pode alcançar E em 5 saltos; e 
assim por diante. Esse ciclo só termina quando as distâncias atingem algum número grande o suficiente 
para ser considerado infinito. Nesse ínterim, nenhum dos nós sabe realmente que E é inalcançável, e 
as tabelas de roteamento da rede não se estabilizam. Essa situação é conhecida como problema da 
contagem até infinito. 

Existem várias soluções parciais para esse problema. A primeira é usar algum número relativamente 
pequeno como uma aproximação de infinito. Por exemplo, poderíamos decidir que o número máximo 
de saltos para atravessar uma rede nunca será maior que 16 e, portanto, escolheríamos 16 como o valor 
que representa infinito. Isso pelo menos limita a quantidade de tempo necessária para contar até “in- 
finito”. Naturalmente, isso também poderia apresentar um problema se nossa rede crescesse até um 
ponto onde alguns nós estivessem separados por mais de 16 saltos. 

Uma técnica para melhorar o tempo de estabilização do roteamento é chamada horizonte dividido. 
A ideia é que, quando um nó envia uma atualização de roteamento aos seus vizinhos, ele não envia as 
rotas que descobriu de cada vizinho de volta para aquele mesmo vizinho. Por exemplo, se B tem a rota 
(E, 2, A) em sua tabela, então ele sabe que deve ter descoberto essa rota a partir de A e, portanto, sempre 
que B envia uma atualização de roteamento para A, ele não incluia rota (E, 2) nessa atualização. Em uma 
variação mais forte do horizonte dividido, chamada horizonte dividido com envenenamento reverso, Bna 
realidade envia essa rota de volta para A, mas coloca informações negativas na rota, para garantir que A 
não usará eventualmente B para chegar a E. Por exemplo, B envia a rota (E, œ) para A. O problema com 
essas duas técnicas é que elas só funcionam para ciclos de roteamento que envolvem dois nós. 

Para ciclos de roteamento maiores, medidas mais drásticas são exigidas. Continuando com o exem- 
plo anterior, se Be C tivessem esperado por um tempo depois de escutar sobre uma falha de enlace de 
A antes de anunciarem rotas para E, eles teriam descoberto que nenhum deles realmente tinha uma 
rota para E. Infelizmente, essa técnica adia a convergência do protocolo; a velocidade de convergência 
é uma das principais vantagens de seu concorrente, o roteamento por estado de enlace, assunto da 
Seção 3.3.3. 


Implementação 

O código que implementa esse algoritmo é muito simples; explicamos apenas os fundamentos aqui. A 
estrutura Route define cada entrada na tabela de roteamento, e a constante MAX TTL especifica por 
quanto tempo uma entrada é mantida na tabela antes de ser descartada. 


fdefine MAX ROUTES 128 /* tamanho máximo da tabela de roteamento */ 
fdefine MAX TTL 120 /* tempo (em segundos) até que a rota expire */ 
typedef struct ( 

NodeAddr Destination; /* endereço de destino */ 

NodeAddr NextHop; /* endereço do próximo salto */ 

int Cost; /* métrica da distância */ 

u short TTL; /* tempo de vida */ 

) Route; 

int numRoutes = 0; 
Route routingTable [MAX ROUTES]; 


A rotina que atualiza a tabela de roteamento do nó local com base em uma nova rota é dada por 
mergeRoute. Embora não seja mostrada, uma função de temporização varre periodicamente a lista de 
rotas na tabela de roteamento do nó, decrementa o campo TTL (tempo de vida) de cada rota e descarta 
quaisquer rotas que tenham um tempo de vida igual a 0. Observe, porém, que o campo TTL é reiniciado 
para MAX TTL sempre que a rota é reconfirmada por uma mensagem de atualização de um nó vizinho. 
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void 
mergeRoute (Route *new) 


{ 


int i; 

for (i = 0; i < numRoutes; ++i) 

{ 

if (new->Destination == routingTable[i].Destination) 


{ 
if (new->Cost + 1 < routingTable[i].Cost) 


{ 


/* encontrou rota melhor: */ 


break; 

} else if (new->NextHop == routingTable[i].NextHop) { 
/* métrica para próximo salto pode ter mudado: */ 
break; 

} else { 

/* rota não é interessabte - apenas ignora */ 
return; 

} 

) 

} 

if (i == numRoutes) 


{ 

/* esta é uma rota totalmente nova; existe espaço 
para ela? */ 

if (numRoutes < MAXROUTES) 

{ 


++numRoutes; 

} else { 

/* não consegue espaço para encaixar rota na tabela e desiste */ 
return; 

} 

} 

routingTable[i] = *new; 


/* reinicia TTL */ 

routingTable[i].TTL = MAX_TTL; 

/* considera salto para chegar ao próximo nó */ 
++routingTable[i] .Cost; 


Finalmente, a rotina updateRoutingTable é a rotina principal que chama mergeRoute para incorporar 
todas as rotas contidas em uma atualização de roteamento que é recebida de um nó vizinho. 


void 
updateRoutingTable (Route *newRoute, int numNewRoutes) 
{ 

ing iz 

for (i=0; i < numNewRoutes; ++i) 


{ 


mergeRoute (&newRoute[i]); 
} 
} 


Routing Information Protocol (RIP) 

Um dos protocolos de roteamento mais usados nas redes IP é o Protocolo de Informações de Roteamento 
(RIP — Routing Information Protocol). Seu uso difundido nos primórdios do IP foi devido em grande parte 
pelo fato de que era distribuído junto com a popular versão Berkeley Software Distribution (BSD) do 
Unix, a partir da qual muitas versões comerciais do Unix foram derivadas. Ele também é extremamente 
simples. O RIP é o exemplo canônico de um protocolo de roteamento montado sobre o algoritmo de 
vetor de distância que acabamos de descrever. 

Os protocolos de roteamento nas inter-redes diferem muito pouco do modelo de grafo idealizado 
descrito anteriormente. Em uma inter-rede, o objetivo dos roteadores é aprender como encaminhar 
pacotes para diversas redes. Assim, ao invés de anunciar o custo de alcançar outros roteadores, os 
roteadores anunciam o custo de alcançar redes. Por exemplo, na Figura 3.30, o roteador C anunciaria 
ao roteador A o fato de que ele pode alcançar as redes 2 e 3 (às quais está diretamente conectado) com 
custo 0, as redes 5 e 6 com custo 1, e a rede 4 com custo 2. 
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0 8 16 31 FIGURA 3.31 Formato de pacote RIPv2. 


FIGURA 3.30 Exemplo de rede executando RIP. 


Comando Versão Deve ser zero 
Família da rede 1 Rótulos de rota 
Prefixo de endereço da rede 1 


Máscara da rede 1 


Distância à rede 1 
Família da rede 2 Rótulos de rota 
Prefixo de endereço da rede 2 


Máscara da rede 2 


Distância à rede 2 


Podemos ver evidência disso no formato de pacote RIP (versão 2) na Figura 3.31. A maior parte do 
pacote é composto por triplas (endereço, máscara, distância). Porém, os princípios do algoritmo de 
roteamento são os mesmos. Por exemplo, se o roteador A descobre do roteador B que a rede X pode 
ser alcançada com um custo menor através de B do que através do próximo salto existente na tabela 
de roteamento, A atualiza a informação de custo e do próximo salto para o número da rede de acordo 
com esta informação. 

O RIP na verdade, é uma implementação bastante simples do roteamento por vetor de distâncias. 
Os roteadores executando RIP enviam seus anúncios a cada 30 segundos; um roteador também envia 
uma mensagem de atualização sempre que uma atualização de outro roteador fizer com que ele altere 
sua tabela de roteamento. Um ponto interessante é que ele admite várias famílias de endereços, não 
apenas IP — esse é o motivo para o campo Família dos anúncios. O RIP versão 2 (RIPv2) também in- 
troduziu as máscaras de sub-rede descritas na Seção 3.2.5, enquanto o RIP versão 1 trabalhava com os 
antigos endereços com classes do IP. 

Como veremos a seguir, é possível usar uma faixa de diferentes métricas ou custos para os enlaces 
em um protocolo de roteamento. O RIP usa a técnica mais simples, com todos os custos de enlace 
sendo iguais a 1, assim como em nosso exemplo anterior. Assim, ele sempre tenta encontrar a rota com 
o número mínimo de saltos. As distâncias válidas são de 1 a 15, com 16 representando infinito. Isso 
também limita a execução do RIP a redes relativamente pequenas - aquelas sem caminhos maiores do 
que 15 saltos. 


3.3.3 Estado do enlace (OSPF) A 


OSPF 
O roteamento por estado do enlace é a segunda principal classe de protocolos de roteamento intrado- 
mínio. As suposições iniciais para o roteamento por estado do enlace são semelhantes àquelas para o 
roteamento por vetor de distâncias. Cada nó é considerado capaz de descobrir o estado do enlace que 
o conecta a seus vizinhos (no sentido de envio e de recepção) e o custo de cada enlace. Novamente, 
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queremos oferecer a cada nó informações suficientes para permitir que ele determine o caminho de 
menor custo até qualquer destino. A ideia básica por trás dos protocolos por estado de enlace é muito 
simples: cada nó sabe como alcançar seus vizinhos aos quais está diretamente conectado, e se garantir- 
mos que a totalidade desse conhecimento é disseminada para cada nó, então cada nó terá conhecimento 
suficiente da rede para montar um mapa completo dela. Essa certamente é uma condição suficiente 
(embora não necessária) para encontrar o caminho mais curto para qualquer ponto na rede. Assim, os 
protocolos por roteamento do estado do enlace contam com dois mecanismos: disseminação confiável 
da informação do estado do enlace e o cálculo de rotas a partir da combinação de todo o conhecimento 
acumulado do estado dos enlaces. 


Inundação confiável 
Inundação confiável é o processo de garantir que todos os nós participantes no protocolo de roteamento 
recebam uma cópia da informação de estado do enlace de todos os outros nós. Como o termo inundação 
sugere, a ideia básica é que um nó envie sua informação de estado do enlace por todos os enlaces aos 
quais está conectado diretamente; cada nó que recebe essa informação, então, a encaminha por todos 
os seus enlaces. Esse processo continua até que a informação tenha alcançado todos os nós na rede. 
Mais precisamente, cada nó cria um pacote de atualização, também chamado pacote de estado do 
enlace (LSP — Link-State Packet), que contém as seguintes informações: 


e OID do nó que criou o LSP. 

e Umalista de vizinhos desse nó aos quais ele está conectado diretamente, com o custo do enlace 
para cada um. 

e Um número de sequência. 

e Um tempo de vida para esse pacote. 


Os dois primeiros itens são necessários para permitir o cálculo da rota; os dois últimos são usados 
para tornar confiável o processo de inundação do pacote a todos os nós. A confiabilidade inclui garantir 
que você tenha a cópia mais recente da informação, pois pode haver vários LSPs contraditórios pro- 
venientes de um mesmo nó atravessando a rede. Tornar a inundação confiável provou-se uma tarefa 
muito difícil. (Por exemplo, uma versão inicial do roteamento por estado do enlace, usada na ARPANET, 
fez com que a rede falhasse em 1981.) 

A inundação funciona da seguinte maneira. Primeiro, a transmissão de LSPs entre roteadores ad- 
jacentes se torna confiável usando confirmações e retransmissões assim como no protocolo confiável 
da camada de enlace, descrito na Seção 2.5. Porém, várias outras etapas são necessárias para inundar 
de modo confiável um LSP para todos os nós em uma rede. 

Considere um nó X que recebe uma cópia de um LSP que foi originado em algum outro nó Y. Observe 
que Y pode ser qualquer outro roteador no mesmo domínio de roteamento de X. X verifica se já arma- 
zenou uma cópia de um LSP deY. Se não, ele armazena o LSP. Se ele já tem uma cópia, ele compara os 
números de sequência; se o novo LSP tiver um número de sequência maior, ele é considerado como 
sendo o mais recente, e esse LSP é armazenado, substituindo o antigo. Um número de sequência 
menor (ou igual) implicaria um LSP mais antigo (ou não mais recente) do que o armazenado, de modo 
que ele seria descartado e nenhuma outra ação seria necessária. Se o LSP recebido fosse mais novo, X 
então enviaria uma cópia desse LSP a todos os seus vizinhos, exceto o vizinho do qual o LSP acabou de 
ser recebido. O fato de que o LSP não é enviado de volta ao nó de onde foi recebido ajuda a encerrar a 
inundação de um LSP Como X passa o LSP adiante para todos os seus vizinhos, que por sua vez fazem 
a mesma coisa, a cópia mais recente do LSP por fim alcança todos os nós. 

A Figura 3.32 mostra um LSP sendo inundado em uma pequena rede. Cada nó fica sombreado quando 
passa a armazenar o novo LSP Na Figura 3.32(a), o LSP chega ao nó X, que o envia aos vizinhos A e C 
na Figura 3.32(b). A e € não o enviam de volta a X, mas o enviam para B. Como B recebe duas cópias 
idênticas do LSP ele aceitará aquela que chegar primeiro e ignorará a segunda, considerada uma du- 
plicata. Depois, ele passa o LSP para D, que não tem vizinhos para inundá-la, e o processo termina. 

Assim como no RIP cada nó gera LSPs sob duas circunstâncias. A expiração de um temporizador 
periódico ou uma mudança na topologia pode fazer com que um nó gere um novo LSP Porém, o único 
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FIGURA 3.32 Inundação dos pacotes de estado do enlace: (a) LSP 
chega ao nó X; (b) X inunda LSP para A e C; (c) A e Cinundam 
LSP para B (mas não para X); (d) inundação concluída. 
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motivo baseado em topologia para um nó gerar um LSP é se um dos enlaces ao qual está conectado 
diretamente ou se um de vizinhos imediatos pararem de operar. A falha de um enlace pode ser detectada 
em alguns casos pelo protocolo da camada de enlace. A saída de um vizinho ou a perda de conectividade 
com esse vizinho pode ser detectada usando pacotes de “olá” periódicos. Cada nó os envia para seus 
vizinhos imediatos em intervalos definidos. Se for passado um tempo suficientemente longo sem o 
recebimento de um “olá” de um vizinho, o enlace para esse vizinho será declarado inativo, e um novo 
LSP será gerado para refletir esse fato. 

Um dos importantes objetivos de projeto do mecanismo de inundação de um protocolo por estado 
do enlace é que a informação mais recente deve ser inundada para todos os nós o mais rapidamente 
possível, enquanto a informação antiga deve ser removida da rede e não ter permissão para circular. 
Além disso, certamente é desejável minimizar a quantidade total de tráfego de roteamento que é en- 
viado ao redor da rede; afinal, isso é apenas overhead do ponto de vista daqueles que realmente usam 
a rede para suas aplicações. Os próximos poucos parágrafos descrevem algumas maneiras como esses 
objetivos são atingidos. 

Um modo fácil de reduzir o overhead é evitar gerar LSPs a menos que seja absolutamente necessário. 
Isso pode ser feito usando temporizadores muito longos - normalmente, da ordem de horas -— para a 
geração periódica de LSPs. Dado que o protocolo de inundação é verdadeiramente confiável quando 
a topologia muda, é seguro considerar que as mensagens dizendo “nada mudou” não precisam ser 
enviadas com frequência. 

Para garantir que a informação antiga seja substituída por novas informações, os LSPs carregam 
números de sequência. Toda vez que um nó gera um novo LSP ele incrementa o número de sequência 
em 1. Diferentemente da maioria dos números de sequência usados em protocolos, não se espera que 
esses números de sequência sejam reiniciados ciclicamente, de modo que o campo precisa ser muito 
grande (digamos, 64 bits). Se um nó parar de funcionar e depois voltar, ele começa com um número de 
sequência 0. Se o nó ficar inativo por muito tempo, todos os LSPs antigos para esse nó terão esgotado 
seu tempo limite (conforme descrevemos a seguir); caso contrário, esse nó eventualmente receberá uma 
cópia do seu próprio LSP com um número de sequência mais alto, que ele pode então incrementar e 
usar como seu próprio número de sequência. Isso garantirá que seu novo LSP substituirá qualquer um 
de seus LSPs antigos remanescentes de um instante anterior à falha do nó. 

OS LSPs também carregam um tempo de vida (TTL). Este é usado para garantir que a informação 
do estado do enlace eventualmente seja removida da rede. Um nó sempre decrementa o TTL de um 
LSP recém-recebido antes de inundá-lo para seus vizinhos. Ele também “envelhece” o LSP enquanto é 
armazenado no nó. Quando o TTL atinge 0, o nó inunda novamente o LSP com um TTL igual a 0, que 
é interpretado por todos os nós na rede como um sinal para excluir esse LSP. 


Cálculo de rota 

Quando determinado nó tem uma cópia do LSP de cada um dos outros nós, ele é capaz de calcular um 
mapa completo da topologia da rede, e a partir desse mapa é capaz de decidir a melhor rota para cada 
destino. A questão, então, é exatamente como ele calcula rotas a partir dessa informação. A solução é 
baseada em um algoritmo bem conhecido da teoria dos grafos — o algoritmo do caminho mais curto 
de Dijkstra. 
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Primeiro, definimos o algoritmo de Dijkstra em termos teóricos de grafo. Imagine que um nó apanhe 
todos os LSPs que recebeu e construa uma representação gráfica da rede, em que N indica o conjunto 
de nós no grafo, [(i,j) indica o custo não negativo (peso) associado à aresta entre os nós ije Ne I(i,j)=co 
se nenhuma aresta conecta i e j. Na descrição a seguir, consideramos que s e N indica esse nó, ou seja, 
o nó executando o algoritmo para encontrar o caminho mais curto para todos os outros nós em N. Além 
disso, o algoritmo mantém as duas variáveis a seguir: M indica o conjunto de nós incorporados até o 
momento pelo algoritmo, e C(n) indica o custo do caminho de s até cada nó n. Dadas essas definições, 
o algoritmo é definido da seguinte forma: 


M= {s} 

para cada nem N - {s} 

C(n) = Ks,n) 

enquanto (N + M) 

M= M V {w} tal que C(w) é o mínimo para todo w em (N- M) 
para cada n em (N - M) 

C(n) = MIN(C(n),C(w) + I(w,n)) 


Basicamente, o algoritmo funciona da seguinte forma. Começamos com M contendo esse nó s e, em 
seguida, inicializamos a tabela de custos (os C(n)s) para os outros nós usando os custos conhecidos para 
os nós conectados diretamente. Depois, procuramos o nó que é alcançável com o menor custo (w) e o 
acrescentamos a M. Finalmente, atualizamos a tabela de custos considerando o custo para alcançar os 
nós através de w. Na última linha do algoritmo, escolhemos uma nova rota para o nó n que passa pelo nó 
w se o custo total de ir da origem até w e depois seguir o enlace de w até n for menor do que a rota antiga 
que tínhamos para n. Esse procedimento é repetido até que todos os nós sejam incorporados a M. 

Na prática, cada switch calcula sua tabela de roteamento diretamente dos LSPs que ela coletou usando 
uma variante do algoritmo de Dijkstra chamada de algoritmo de busca direta. Especificamente, cada switch 
mantém duas listas, conhecidas como Tentativa e Confirmado. Cada uma dessas listas contém um conjunto 
de entradas na forma (Destino, Custo, PróximoSalto). O algoritmo funciona da seguinte forma: 


1. Inicialize a lista Confirmado com uma entrada para si mesma; essa entrada tem um custo de 0. 

2. Para o nó recém-incluído na lista Confirmado da etapa anterior, chame-o de nó Próximo e 
selecione seu LSP. 

3. Para cada vizinho (Vizinho) de Próximo, calcule o custo (Custo) para alcançar seu Vizinho como a 
soma do custo partindo de si mesmo até Próximo e de Próximo até Vizinho. 

(a) Se Vizinho não estiver atualmente nem na lista Confirmado nem na lista Tentativa, então 
acrescente (Vizinho, Custo, PróximoSalto) à lista Tentativa, onde PróximosSalto é a direção que 
se deve seguir para alcançar Próximo. 

(b) Se Vizinho estiver atualmente na lista Tentativa, e o valor de Custo for menor que o custo 
atualmente listado para Vizinho, então substitua a entrada atual por (Vizinho, Custo, 
PróximosSalto), onde PróximoSalto é a direção que se deve seguir para alcançar Próximo. 

4. Se a lista Tentativa estiver vazia, pare. Caso contrário, escolha a entrada da lista Tentativa com o 

menor custo, mova-a para a lista Confirmado e retorne à etapa 2. 


Isso se tornará muito mais fácil de entender quando examinarmos um exemplo. Considere a rede 
representada na Figura 3.33. Observe que, diferente do nosso exemplo anterior, esta rede tem um in- 
tervalo de diferentes custos de aresta. A Tabela 3.14 traça as etapas para montar a tabela de roteamento 








FIGURA 3.33 Roteamento por estado do enlace: um exemplo de rede. 
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Tabela 3.14 Etapas para montar a tabela de roteamento para o nó D (Figura 3.33) 





Etapa Confirmado Tentativa Comentários 

1 (D,0,—) Como D é o único membro da lista de confirmados, 
examine seu LSP. 

2 (D,0,—) (B,11,B) (C,2,0) LSP de D diz que podemos alcançar B através de B com 


custo 11, que é melhor do que qualquer outra coisa 
em qualquer lista e, portanto, o colocamos na lista 
Tentativa; o mesmo vale para C. 

3 (D,0,> (C,2,C) (B,11,B) Coloque o membro de menor custo da lista Tentativa 
(C) na lista Confirmado. Em seguida, examine o LSP do 
membro recém-confirmado (C). 

4 (D,0,> (€,2,0) (B,5,0) (A,12,0) Custo para alcançar B através de C é 5, portanto 
substitua (B,11,B). O LSP de C nos diz que podemos 
alcançar A com custo 12. 


5 (D,0,>) (C,2,C) (B,5,C) (A,12,C) Mova o membro de menor custo da lista Tentativa (B) 
para a lista Confirmado, depois examine seu LSP. 

6 (D,0,5 (C,2,C) (B,5,C) (A,10,C) Como podemos alcançar A com custo 5 através de B, 
substitua a entrada na lista Tentativa. 

7 (D,0,> (C,2,C) (B,5,0) (A,10,C) Mova o membro de menor custo da lista Tentativa (A) 


para Confirmado e finalize o processo. 


para o nó D. Indicamos as duas saídas de D usando os nomes dos nós aos quais eles se conectam, 
Be C. Observe o modo como o algoritmo parece impedir pistas falsas (como o caminho com custo 
de 11 unidades até B que foi a primeira inclusão na lista Tentativa), mas acaba obtendo os caminhos de 
menor custo para todos os nós. 

O algoritmo de roteamento do estado do enlace tem muitas propriedades interessantes. Demons- 
tra-se que ele se estabiliza rapidamente, não gera muito tráfego e responde rapidamente a mudanças 
de topologia ou falhas de nó. Pelo lado negativo, a quantidade de informações armazenadas em cada 
nó (um LSP para cada outro nó na rede) pode ser muito grande. Esse é um dos problemas fundamentais 
do roteamento e é um exemplo do problema mais geral de escalabilidade. Algumas soluções para o 
problema específico (a quantidade de armazenamento potencialmente exigido em cada nó) e para 
o problema geral (escalabilidade) serão discutidas na próxima seção. 


A diferença entre os algoritmos por vetor de distâncias e por estado do enlace pode ser resumida da seguinte 
forma. No vetor de distâncias, cada nó fala somente com seus vizinhos aos quais está diretamente conectado, 


mas lhes informa tudo o que descobriu (ou seja, a distância para todos os nós). No estado do enlace, cada nó 
fala com todos os outros nós, mas lhes diz somente o que ele sabe com certeza (ou seja, apenas o estado de 
seus enlaces aos quais está conectado diretamente). 





O Protocolo Open Shortest Path First (OSPF) 

Um dos protocolos de roteamento por estado do enlace mais usado é o Protocolo Aberto de Menor Rota 
Primeiro (OSPF — Open Shortest Path First). A primeira palavra, “Open” (aberto), refere-se ao fato de que 
ele é um padrão aberto, não patenteado, criado sob os auspícios da Internet Engineering Task Force (IETF). 
A parte “SPF” vem do nome alternativo para o roteamento por estado do enlace. O OSPF acrescenta 
diversos recursos ao algoritmo básico do estado do enlace, descrito acima, incluindo o seguinte: 


e Autenticação de mensagens de roteamento — um recurso dos algoritmos de roteamento distribuído 
é que eles dispersam informações de um nó para muitos outros nós, e a rede inteira pode assim 
ser afetada por informações erradas de um nó. Por esse motivo, é uma boa ideia ter certeza de que 
todos os nós que tomam parte do protocolo podem ser confiáveis. A autenticação de mensagens 
de roteamento ajuda a conseguir isso. As primeiras versões do OSPF usavam uma senha simples de 
8 bytes para a autenticação. Essa não é uma forma de autenticação forte o suficiente para impedir 
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usuários maliciosos dedicados, mas alivia alguns problemas causados por erro de configuração ou 
ataques casuais. (Uma forma de autenticação semelhante foi acrescentada ao RIP na versão 2.) A 
autenticação criptográfica forte, do tipo discutido na Seção 8.3, foi acrescentada mais tarde. 

e Hierarquia adicional- a hierarquia é uma das ferramentas fundamentais usadas para tornar os 
sistemas mais escaláveis. O OSPF introduz outra camada de hierarquia no roteamento, permitindo 
que um domínio seja particionado em áreas. Isso significa que um roteador dentro de um domínio 
não necessariamente precisa saber como alcançar cada rede dentro desse domínio — ele pode ser 
capaz de desempenhar bem seu papel sabendo apenas como chegar à área certa. Assim, há uma 
redução na quantidade de informação que precisa ser transmitida e armazenada em cada nó. 
Examinamos as áreas em detalhes na Seção 4.1.1. 

e Balanceamento de carga - O OSPF permite que várias rotas para o mesmo local recebam o mesmo 
custo e façam com que o tráfego seja distribuído por igual por essas rotas, fazendo assim um 
melhor uso da capacidade de rede disponível. 


Existem vários tipos diferentes de mensagens OSPE mas todas começam com o mesmo cabeçalho, 
como mostra a Figura 3.34. O campo Versão é atualmente fixado em 2, e o campo Tipo pode assumir os 
valores de 1 a 5. O EndereçoOrigem identifica o emissor da mensagem, e o Areald é um identificador de 
32 bits da área em que o nó está localizado. O pacote inteiro, exceto os dados de autenticação, é protegido 
por uma soma de verificação de 16 bits usando o mesmo algoritmo do cabeçalho IP (ver Seção 2.4). O 
campo Tipo de autenticação vale O se nenhuma autenticação for usada; caso contrário, ele pode ser 
1, significando que uma senha simples é usada, ou 2, que indica que uma soma de verificação cripto- 
gráfica, do tipo descrito na Seção 8.3, é utilizada para a autenticação. Nesses últimos casos, o campo 
Autenticação carrega a senha ou a soma de verificação criptográfica. 

Dos cinco tipos de mensagem OSPF o tipo 1 é a mensagem “olá”, que um roteador envia aos seus 
pares para notificá-los que ainda está ativo e conectado, conforme descrito anteriormente. Os tipos 
restantes são usados para solicitar, enviar e confirmar o recebimento das mensagens de estado do 
enlace. O bloco construtivo básico das mensagens de estado do enlace no OSPF é o anúncio de estado 
do enlace (LSA — Link-State Advertisement). Uma mensagem pode conter muitos LSAs. Fornecemos 
alguns detalhes do LSA aqui. 

Assim como qualquer protocolo de roteamento inter-rede, o OSPF precisa fornecer informações 
sobre como alcançar as redes. Portanto, o OSPF precisa oferecer um pouco mais de informações do que 
o protocolo simples baseado em grafos descrito anteriormente. De modo mais específico, um roteador 
usando OSPF pode gerar pacotes de estado do enlace que anunciam uma ou mais das redes que estão 
diretamente conectadas a esse roteador. Além disso, um roteador que está conectado a outro roteador 
por algum enlace precisa anunciar o custo de alcançar esse roteador pelo enlace. Esses dois tipos de 
anúncios são necessários para permitir que todos os roteadores em um domínio determinem o custo 
de alcançar todas as redes nesse domínio e o próximo salto apropriado para cada rede. 

A Figura 3.35 mostra o formato de pacote para um anúncio de estado do enlace do tipo 1. Os LSAs 
de tipo 1 anunciam o custo dos enlaces entre os roteadores. LSAs de tipo 2 são usados para anunciar 
redes às quais o roteador fazendo o anúncio está conectado, enquanto outros tipos são usados para dar 
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Mais enlaces 


FIGURA 3.34 Formato do cabeçalho OSPF. FIGURA 3.35 Anúncio de estado do enlace OSPF. 
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suporte a hierarquia adicional, conforme descrito na próxima seção. Muitos campos no LSA deverão ser 
familiares pela discussão anterior. O campo Idade do LS é o equivalente de um tempo de vida, exceto 
que ele é incrementado repetidamente e o LSA expira quando a idade atinge um valor máximo definido. 
O campo Tipo nos diz que esse é um LSA tipo 1. 

Em um LSA tipo 1, os campos ID estado enlace e Roteador fazendo anúncio são idênticos. Cada um 
transporta um identificador de 32 bits do roteador que criou esse LSA. Embora diversas estratégias de 
atribuição possam ser usadas para atribuir esse ID, é essencial que ele seja exclusivo no domínio de 
roteamento e que um determinado roteador use consistentemente o mesmo ID de roteador. Um modo 
de escolher um ID de roteador que atende a esses requisitos seria escolher o endereço IP mais baixo 
entre todos os endereços IP atribuídos a esse roteador. (Lembre que um roteador pode ter um endereço 
IP diferente em cada uma de suas interfaces.) 

O campo Número sequência LS é usado exatamente conforme descrito anteriormente para detectar 
LSAs antigos ou duplicados. A Soma de verificação LS é semelhante a outras que vimos na Seção 2.4 e em 
outros protocolos; esse campo, obviamente, é usado para verificar se os dados não foram modificados. 
Ele cobre todos os campos no pacote, exceto Idade LS, de modo que não é necessário recalcular a soma 
de verificação toda vez que o campo Idade LS é incrementado. O campo Comprimento corresponde ao 
comprimento em bytes do LSA completo. 

Agora, vamos passar à informação de estado do enlace de fato. Isso se torna um pouco complicado 
pela presença da informação de TOS (tipo de serviço). Ignorando isso por um instante, cada enlace no 
LSA é representado por um campo de ID enlace, um capo de Dados enlace e um campo de métrica. 
Os dois primeiros desses campos identificam o enlace; um modo comum de fazer isso seria usar o 
ID do roteador na extremidade do enlace como ID enlace e então usar o campo Dados enlace para 
resolver qualquer ambiguidade entre vários enlaces paralelos, se for preciso. A métrica, naturalmente, 
corresponde ao custo do enlace. Tipo nos diz algo sobre o enlace — por exemplo, se ele é um enlace 
ponto a ponto. 

A informação de TOS está presente para permitir que o OSPF escolha diferentes rotas para pacotes 
IP com base no valor em seu campo TOS. Ao invés de atribuir uma única métrica a um enlace, é pos- 
sível atribuir diferentes métricas, dependendo do valor de TOS dos dados. Por exemplo, se tivéssemos 
um enlace em nossa rede que fosse muito bom para transportar tráfego sensível ao atraso, poderíamos 
lhe atribuir uma métrica baixa para o valor de TOS correspondente a um atraso baixo e uma métrica 
alta para tudo o mais. O OSPF tomaria então um caminho mais curto diferente para os pacotes que 
tivessem aquele valor em seu campo de TOS. Vale a pena observar que, no momento em que este livro 
era escrito, essa capacidade ainda não havia sido amplamente implantada.!” 


3.3.4 Métrica 


A discussão anterior considera que os custos do enlace, ou métricas, são conhecidos quando exe- 
cutamos o algoritmo de roteamento. Nesta seção, veremos algumas maneiras de calcular os custos 
do enlace que se provaram eficazes na prática. Um exemplo que já vimos, que é bastante razoável e 
muito simples, é atribuir um custo de 1 a todos os enlaces — a rota com menor custo será aquela com 
menos saltos. Porém, essa técnica tem várias desvantagens. Primeiro, ela não distingue entre enlaces 
com base em sua latência. Assim, um enlace de satélite com latência de 250 ms parece tão atraente 
ao protocolo de roteamento quanto um enlace terrestre de 1 ms. Segundo, ela não distingue entre 
rotas com base em sua capacidade, tornando um enlace de 9,6 kbps tão bom quanto um enlace de 
45 Mbps. Por fim, ela não distingue entre os enlaces com base em sua carga atual, tornando impos- 
sível contornar enlaces sobrecarregados. Acontece que esse último problema é o mais complicado, 
pois você está tentando capturar as características complexas e dinâmicas de um enlace por meio de 
um único custo escalar. 


"Observe também que o significado do campo TOS mudou desde que a especificação do OSPF foi escrita. Esse tópico 
é discutido na Seção 6.5.3. 
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A ARPANET foi a base de testes para uma série de técnicas diferentes para o cálculo de custo do 
enlace. (Ela também foi o local onde a estabilidade superior do roteamento por estado do enlace em 
comparação com o vetor de distâncias foi demonstrada; o mecanismo original usava o vetor de dis- 
tâncias, enquanto a versão mais recente usava estado do enlace.) A discussão a seguir acompanha 
a evolução da métrica de roteamento da ARPANET e, ao fazer isso, explora os aspectos sutis do pro- 
blema. 

A métrica de roteamento original da ARPANET media o número de pacotes que estavam enfileirados 
aguardando para serem transmitidos em cada enlace, significando que um enlace com 10 pacotes enfi- 
leirados, aguardando para serem transmitidos, recebia um peso com custo maior do que um enlace com 
5 pacotes enfileirados para transmissão. Porém, o uso do tamanho da fila como métrica de roteamento 
não funcionou muito bem, pois o tamanho da fila é uma medida artificial da carga — ela move pacotes 
para a fila mais curta, em vez de para o destino, uma situação muito familiar àqueles que costumam 
passar de uma fila para outra no caixa do supermercado. De um modo mais preciso, o mecanismo de 
roteamento original da ARPANET apresentava problemas porque não levava em consideração nem a 
largura de banda nem a latência do enlace. 

Uma segunda versão do algoritmo de roteamento da ARPANET, às vezes chamada de novo meca- 
nismo de roteamento, levava em conta tanto a largura de banda quanto a latência e usava o atraso, 
ao invés do tamanho da fila, como uma medida de carga do enlace. Isso era feito da seguinte forma. 
Primeiro, cada pacote que chegava recebia um carimbo de tempo (timestamp) com sua hora de 
chegada no roteador (HoraChegada); sua hora de saída do roteador (HoraSaída) também era regis- 
trada. Segundo, quando o ACK em nível de enlace era recebido do outro lado, o nó calculava o atraso 
para esse pacote como 


Atraso = (HoraSaída — HoraChegada) + TempoTransmissão + Latência 


onde TempoTransmissão e Latência eram definidos estaticamente para o enlace e capturavam a 
largura de banda e a latência do enlace, respectivamente. Observe que, neste caso, HoraSaída — Hora- 
Chegada representa a quantidade de tempo em que o pacote foi atrasado (enfileirado) no nó devido 
à carga da rede. Se o ACK não chegasse, mas em vez disso o pacote esgotasse seu tempo limite, então 
HoraSaída era reiniciada para a hora em que o pacote foi retransmitido. Nesse caso, HoraSaída — Hora- 
Chegada captura a confiabilidade do enlace — quanto mais frequente for a retransmissão de pacotes, 
menos confiável é o enlace, e mais desejaremos evitá-lo. Por fim, o peso atribuído a cada enlace era 
derivado do atraso médio experimentado pelos pacotes enviados recentemente por esse enlace. 

Embora sendo uma melhoria em relação ao mecanismo original, essa abordagem também tinha 
muitos problemas. Sob carga leve, ela funcionava razoavelmente bem, pois os dois fatores estáticos do 
atraso dominavam o custo. Sob carga pesada, porém, um enlace congestionado começaria a anunciar 
um custo muito alto. Isso fazia com que todo o tráfego saísse desse enlace, deixando-o ocioso, de modo 
que ele anunciaria um custo baixo, atraindo assim todo o tráfego de volta, e assim por diante. O efeito 
dessa instabilidade era que, sob carga pesada, muitos enlaces de fato gastavam muito tempo ficando 
ociosos, que é a última coisa que você deseja sob carga pesada. 

Outro problema era que o intervalo de valores do enlace era muito grande. Por exemplo, um 
enlace de 9,6 kbps bastante carregado poderia parecer 127 vezes mais custoso do que um enlace 
de 56 Kbps pouco carregado. Isso significa que o algoritmo de roteamento escolheria um caminho 
composto por 126 saltos de enlaces de 56 kbps pouco carregados em vez de um caminho de 1 salto 
com 9,6 kbps. Embora desviar algum tráfego de uma linha sobrecarregada seja uma boa ideia, tornar 
tal linha tão pouco atrativa que ela chegue a perder todo o seu tráfego é algo excessivo. Usar 126 
saltos enquanto 1 salto resolveria o problema é, em geral, um mau uso dos recursos da rede. Além 
disso, os enlaces via satélite foram indevidamente penalizados, de modo que um enlace via satélite 
ocioso de 56 kbps parecia consideravelmente mais custoso do que um enlace terrestre ocioso de 
9,6 kbps, embora o primeiro ofereça um desempenho melhor para aplicações que exigem elevada 
largura de banda. 
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Uma terceira técnica, chamada “métrica de roteamento ARPANET revisada”, resolveu esses pro- 
blemas. As principais vantagens foram comprimir consideravelmente o intervalo dinâmico da métrica, 
levar em consideração o tipo do enlace e suavizar a variação da métrica ao longo do tempo. 

A suavização foi alcançada por vários mecanismos. Primeiro, a medição do atraso foi transformada 
em uma utilização do enlace, e esse número tinha sua média calculada com o último valor de utilização 
reportado, de modo a suprimir mudanças repentinas. Segundo, havia um limite rígido sobre o quanto 
a métrica poderia mudar de um ciclo de medição para o seguinte. Com a suavização das mudanças 
no custo, a probabilidade de que todos os nós abandonassem uma rota de uma só vez foi bastante 
reduzida. 

A compressão do intervalo dinâmico foi conseguida alimentando-se a utilização medida, o tipo do 
enlace e a velocidade do enlace em uma função que é mostrada graficamente na Figura 3.36. Observe 
o seguinte: 


e Um enlace altamente carregado nunca apresenta um custo de mais do que três vezes seu custo 
quando ocioso. 

e O enlace mais caro tem apenas sete vezes o custo do mais barato. 

e QOenlace por satélite de alta velocidade é mais atraente do que o enlace terrestre de baixa 
velocidade. 

e O custo é uma função da utilização do enlace apenas em cargas moderadas a altas. 


Todos esses fatores significam que um enlace é muito menos provável de ser abandonado universal- 
mente, pois um aumento de três vezes no custo provavelmente tornará o enlace pouco atraente para 
alguns caminhos, mas permite que ele continue sendo a melhor escolha para outros. As inclinações, os 
deslocamentos e pontos de interrupção das curvas da Figura 3.36 foram obtidos após muita tentativa 
e erro, e foram ajustados cuidadosamente para fornecer um bom desempenho. 

Finalizamos nossa discussão sobre métricas de roteamento com uma dose de realidade. Na maioria 
das implantações de redes no mundo real quando da escrita deste livro, as métricas se alteram raramente, 
ou mesmo nunca, e apenas sob o controle de um administrador da rede, não automaticamente como 
foi descrito acima. A razão para isto é, em parte, que a sabedoria convencional dita atualmente que 
métricas que se alteram dinamicamente são muito instáveis, embora isto provavelmente não precise ser 
verdadeiro. Talvez de forma mais significativa, muitas redes hoje não apresentam a grande disparidade 
das velocidades de conexão e latências que prevaleciam na ARPANET. Assim, métricas estáticas são a 
norma. Uma abordagem comum para definir métricas é usar uma constante multiplicada por (1/largura 
de banda do enlace). 
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FIGURA 3.36 Métrica de roteamento ARPANET revisado versus utilização do enlace. 
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MONITORANDO O COMPORTAMENTO DO ROTEAMENTO 


Dada a complexidade do roteamento de pacotes por meio de uma rede da escala da Internet, poderíamos 
questionar se esse sistema funciona bem. Sabemos que ele funciona parte do tempo porque conseguimos 
nos conectar a sites em todo o mundo. Porém, suspeitamos que ele não funcione o tempo todo porque às 
vezes não conseguimos nos conectar a certos sites. O problema real é determinar qual parte do sistema 
está com defeito quando nossas conexões falham: algum mecanismo de roteamento deixou de funcionar 
corretamente, o servidor remoto está muito ocupado ou algum enlace ou máquina simplesmente parou de 
funcionar? 

Isso é realmente uma questão de gerenciamento de redes, e embora existam ferramentas que os 
administradores do sistema usem para cuidar de suas próprias redes — por exemplo, veja o Simple Network 
Management Protocol (SNMP) descrito na Seção 9.3.2 — esse é um problema em grande parte não resolvido 
para a Internet como um todo. De fato, a Internet se tornou tão grande e complexa que, embora ela seja 
construída a partir de uma coleção de partes criadas pelo homem e bastante determinísticas, passamos a 
vê-la quase como um organismo vivo ou um fenômeno natural que deve ser estudado. Ou seja, tentamos 
entender o comportamento dinâmico da Internet realizando experimentos sobre ela e propondo modelos 
que expliquem nossas observações. 

Um excelente exemplo desse tipo de estudo foi realizado por Vern Paxon. Paxon usou a ferramenta 
traceroute para estudar 40 mil rotas fim a fim entre 36 sites da Internet em 1995. Ele estava tentando responder 
a perguntas sobre como as rotas falham, qual a estabilidade das rotas com o passar do tempo e se elas são 
ou não simétricas. Entre outras coisas, Paxson descobriu que a probabilidade de um usuário encontrar um 
problema sério de roteamento fim a fim era de 1 em 30, e que esses problemas normalmente duravam cerca 
de 30 segundos. Ele também descobriu que dois terços das rotas da Internet persistiam por dias ou semanas e 
que, cerca de um terço do tempo, a rota usada para chegar do host A ao host B incluía pelo menos um domínio 
de roteamento diferente da rota usada para chegar do host B ao host A. A conclusão geral de Paxson foi que o 
roteamento na Internet estava se tornando cada vez menos previsível com o passar do tempo. 





3.4 Implementação e desempenho 


Até aqui, falamos sobre o que os switches e roteadores devem fazer sem discutir como fazê-lo. Há 
um modo muito simples de montar um switch ou roteador: compre um processador de uso geral e 
equipe-o com uma série de interfaces de rede. Esse dispositivo, executando software adequado, pode 
receber pacotes em uma de suas interfaces, realizar qualquer uma das funções de comutação ou 
encaminhamento descritas anteriormente e enviar pacotes por outra de suas interfaces. Este, de fato, 
é um modo popular de montar roteadores e switches experimentais quando você deseja ser capaz de 
fazer coisas como desenvolver novos protocolos de roteamento, pois oferece flexibilidade extrema e 
um ambiente de programação familiar. Isso também não é muito distante da arquitetura de muitos 
roteadores comerciais menos potentes. 


3.4.1 Fundamentos de um comutador 


Switches e roteadores utilizam técnicas de implementação semelhantes, de modo que começaremos 
esta seção examinando essas técnicas comuns, depois prosseguiremos para ver as questões específicas 
afetando a implementação de roteadores na Seção 3.4.4. Para a maior parte desta seção, usaremos 
a palavra comutador para cobrir os dois tipos de dispositivos, pois seus projetos internos são muito 
semelhantes (e é tedioso dizer “switch ou roteador” o tempo todo). 

A Figura 3.37 mostra um processador com três interfaces de rede usadas como um comutador. A figura 
mostra um caminho que um pacote poderia seguir do momento em que chega na interface 1 até quando 
ele é enviado pela interface 2. Consideramos aqui que o processador tem um mecanismo para mover 
dados diretamente de uma interface para sua memória principal sem que eles precisem ser copiados 
diretamente pela CPU, uma técnica chamada acesso direto à memória (DMA — Direct Memory Access). 
Quando o pacote está na memória, a CPU examina seu cabeçalho para determinar para qual interface o 
pacote deverá ser enviado. Depois, ela usa DMA para mover o pacote para a interface apropriada. Observe 
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FIGURA 3.37 Um processador de uso geral usado 


Barramento de E/S como comutador de pacotes. 
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que a Figura 3.37 não mostra o pacote saindo para a CPU porque a CPU inspeciona apenas o cabeçalho 
do pacote; ela não precisa ler cada byte de dados no pacote. 

O problema principal com o uso de um processador de uso geral como um comutador é que seu 
desempenho é limitado pelo fato de que todos os pacotes devem passar por um único ponto de disputa: 
no exemplo mostrado, cada pacote atravessa o barramento de E/S duas vezes e é escrito na memória 
principal e lido dela uma vez. O limite superior da vazão agregada desse dispositivo (a taxa de trans- 
ferência de dados total que pode ser sustentada considerando a soma de todas as entradas) é, portanto, 
ou metade da largura de banda da memória principal ou metade da largura de banda do barramento de 
E/S: o valor que for menor. (Normalmente, o menor valor é a largura de banda do barramento de E/S.) 
Por exemplo, uma máquina com um barramento de E/S de 64 bits operando a 133 MHz pode transmitir 
dados a uma taxa máxima de pouco mais de 8 Gbps. Como o encaminhamento de um pacote envolve 
a travessia do barramento duas vezes, o limite real é de 5 Gbps - suficiente para montar um comutador 
com um número razoável de portas Ethernet de 100 Mbps, por exemplo, mas não suficiente para um 
roteador de alto desempenho no núcleo da Internet. 

Além disso, esse limite superior também considera que a movimentação de dados é o único pro- 
blema — uma aproximação razoável para pacotes longos, mas ruim quando os pacotes são curtos. 
Nesse último caso, o custo de processar cada pacote — analisar seu cabeçalho e decidir por qual 
enlace de saída transmiti-lo - provavelmente será o fator dominante. Suponha, por exemplo, que um 
processador possa realizar todo o processamento necessário para comutar 2 milhões de pacotes a 
cada segundo. Essa taxa às vezes é chamada de pacotes por segundo (pps). (Esse número representa 
o que pode ser alcançado em um PC modesto.) Se o pacote normalmente é curto, digamos, com 
64 bytes, isso implicaria 


Vazão = pps x (BitsPorPacote) 
=2 x 10º x 64x8 
=1024 x 10º 


ou seja, uma vazão de cerca de 1 Gpbs — substancialmente abaixo da faixa que os usuários estão exigin- 
do de suas redes atualmente. Lembre que esses 1 Gbps seriam compartilhados por todos os usuários 
conectados ao comutador, assim como a largura de banda de um único segmento Ethernet (não comu- 
tado) é compartilhada entre todos os usuários conectados ao meio compartilhado. Assim, por exemplo, 
um comutador de 20 portas com essa vazão agregada só poderia lidar com uma taxa de transferência 
de dados média de cerca de 50 Mbps em cada porta. 

Para resolver esse problema, os projetistas de hardware apareceram com uma grande variedade 
de projetos de comutador que reduzem a quantidade de disputa e oferecem elevada vazão agregada. 
Observe que alguma disputa é inevitável: se cada entrada tiver dados para enviar a uma única saída, 
então elas não podem enviá-los ao mesmo tempo. Porém, se os dados destinados para diferentes saídas 
estiverem chegando em diferentes entradas, então um comutador bem projetado será capaz de mover 
dados de entradas para saídas de forma paralela, aumentando assim a vazão agregada. 
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DEFINIÇÃO DE VAZÃO 


Acontece que é difícil definir exatamente a vazão de um comutador. Intuitivamente, poderíamos pensar 
que, se um comutador tem n entradas que admitem uma velocidade de enlace s; cada uma, então a vazão 
seria simplesmente a soma de todos os s;. Esta é realmente a melhor vazão possível que tal comutador 
poderia oferecer, mas na prática quase nenhum comutador real pode garantir esse nível de desempenho. 
Um motivo para isso é simples de entender. Suponha que, por algum período de tempo, todo o tráfego que 
chega no comutador precisa ser enviado à mesma saída. Contanto que a largura de banda dessa saída seja 
menor do que a soma das larguras de banda das entradas, então parte do tráfego precisaria ser mantida em 
buffer ou descartada. Com esse padrão de tráfego em particular, o comutador não poderia oferecer um vazão 
sustentada maior do que a velocidade do enlace dessa única saída. Porém, um comutador poderia ser capaz 
de lidar com o tráfego que chega na velocidade máxima do enlace em todas as entradas se tal tráfego for 
distribuído por todas as saídas uniformemente; isso seria considerado ideal. 

Outro fator que afeta o desempenho de comutadores é o tamanho dos pacotes que chegam nas entradas. 
Para um comutador ATM, isso normalmente não é um problema, pois todos os “pacotes” (células) têm o 
mesmo tamanho. Porém, para switches Ethernet ou roteadores IP pacotes de tamanhos bastante variáveis 
são possíveis. Algumas das operações que um comutador precisa realizar apresentam overhead constante 
por pacote, de modo que um comutador provavelmente funcionará de forma diferente dependendo se todos 
os pacotes que chegam são muito curtos, muito longos ou uma mistura dos dois tipos. Por esse motivo, os 
roteadores ou switches que encaminham pacotes de tamanho variável normalmente são caracterizados por 
uma taxa de transferência de pacotes por segundo, além de uma vazão em bits por segundo. A taxa de pps 
normalmente é medida com pacotes de tamanho mínimo. 

A primeira coisa a observar sobre essa discussão é que a vazão de um comutador é uma função do tráfego ao 
qual ele está sujeito. Uma das coisas que os projetistas de comutadores gastam muito do seu tempo fazendo é 
tentando chegar a modelos de tráfego que aproximam o comportamento do tráfego de dados real. Acontece que 
é extremamente difícil obter modelos precisos. Existem vários elementos em um modelo de tráfego. Os principais 
são (1) quando os pacotes chegam, (2) para quais saídas eles são destinados e (3) qual é o seu tamanho. 

A modelagem de tráfego é uma ciência bem estabelecida, que tem sido extremamente bem-sucedida no 
mundo da telefonia, permitindo que companhias telefônicas projetem suas redes para transportar as cargas 
esperadas de modo bastante eficaz. Isso ocorre parcialmente porque o modo como as pessoas usam a rede 
telefônica não muda tanto com o tempo: a frequência com que as chamadas são feitas, a quantidade de 
tempo gasta para uma chamada e a tendência de todos fazerem ligações no Dia das Mães têm permanecido 
constantes por muitos anos. Por outro lado, a rápida evolução das comunicações por computador, onde 
uma nova aplicação como o BitTorrent pode mudar os padrões de tráfego quase da noite para o dia, tornou 
a modelagem eficaz das redes de computadores muito mais difícil. Apesar disso, existem alguns excelentes 
livros e artigos sobre o assunto, que listamos ao final do capítulo. 

Para que você tenha uma ideia da gama de vazões com as quais os projetistas precisam se preocupar, um 
único roteador em rack usado no núcleo da Internet no momento em que este livro foi escrito era capaz de 
suportar 16 enlaces OC-768, fornecendo uma vazão de aproximadamente 640 Gbps. Um switch de 640 Gbps, 
se tivesse que lidar com um fluxo constante de pacotes de 64 bytes, precisaria de uma taxa de pacotes por 
segundo de 


640x10° +(64x8)=1,25x10° pps 





3.4.2 Portas 


A maioria dos comutadores parece conceitualmente semelhante àquele mostrado na Figura 3.38. Eles 
consistem em uma série de portas de entrada e de saída e uma malha. Normalmente, há pelo menos um 
processador de controle encarregado do comutador inteiro que se comunica com as portas diretamente 
ou, como vemos aqui, por meio da malha de comutação. As portas se comunicam com o mundo ex- 
terior. Elas podem conter receptores de fibra óptica e lasers, buffers para armazenar pacotes que estão 
esperando para serem comutados ou transmitidos, e frequentemente uma quantidade significativa de 
outros circuitos, permitindo que o comutador funcione. A malha tem uma tarefa muito simples e bem 
definida: quando recebe um pacote, ela deve entregá-lo à porta de saída. 
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FIGURA 3.38 Um comutador 4x4. 
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Uma das tarefas das portas, portanto, é lidar com a complexidade do mundo real de tal forma que a 
malha possa realizar sua tarefa, que é relativamente simples. Por exemplo, suponha que esse comutador 
esteja fornecendo suporte a um modelo de comunicação por circuitos virtuais. Em geral, as tabelas 
de mapeamento do circuito virtual descritas na Seção 3.1.2 estão localizadas nas portas. As portas 
mantêm listas de identificadores de circuito virtual que estão atualmente em uso, com informações 
sobre para qual saída um pacote deve ser enviado para cada VCI e como o VCI precisa ser remapeado 
para garantir que os valores no enlace de saída sejam unívocos. De modo semelhante, as portas de um 
switch Ethernet armazenam tabelas que mapeiam entre endereços Ethernet e portas de saída (tabelas 
de encaminhamento de ponte, conforme descrito na Seção 3.1.4). Em geral, quando um pacote é en- 
tregue de uma porta de entrada para a malha, a porta descobriu para onde o pacote precisa ir, e esta 
porta ou configura a malha de acordo transmitindo alguma informação de controle para ela ou adiciona 
informações suficientes ao próprio pacote (por exemplo, um número de porta de saída) para permitir 
que a malha faça sua tarefa automaticamente. Malhas que comutam pacotes examinando apenas a 
informação no pacote são chamadas de autorroteáveis, pois elas não precisam de controle externo para 
rotear pacotes. Um exemplo de uma malha autorroteável é discutido a seguir. 

A porta de entrada é o primeiro lugar onde deve-se procurar por gargalos de desempenho. A porta de 
entrada precisa receber um fluxo constante de pacotes, analisar as informações no cabeçalho de cada 
um deles para determinar para qual porta (ou portas) de saída o pacote precisa ser enviado e passar 
o pacote para a malha. O tipo de análise de cabeçalho que ela realiza pode variar desde uma simples 
busca por um VCI em uma tabela até algoritmos de correspondência complexos, que examinam muitos 
campos no cabeçalho. Esse é o tipo de operação que às vezes se torna um problema quando o tamanho 
médio do pacote é muito pequeno. Considere, por exemplo, pacotes de 64 bytes chegando em uma porta 
conectada a um enlace OC-48 (2,48 Gbps). Tal porta precisa processar pacotes a uma taxa de 


2,48x10º =(64x8)=4,83x10º pps 


Em outras palavras, quando os pacotes estão chegando o mais rápido possível nesse enlace (o 
cenário do pior caso com o qual a maioria das portas estão preparadas para lidar), a porta de entrada 
tem aproximadamente 200 nanossegundos para processar cada pacote. 

Outra função chave das portas é a bufferização (ou seja, colocar dados em um buffer). Observe que a 
bufferização pode acontecer na porta de entrada ou de saída; ela também pode acontecer dentro da malha 
(às vezes chamada de bufferização interna). A simples bufferização da entrada tem algumas limitações 
sérias. Considere um buffer de entrada implementado como uma fila FIFO. À medida que os pacotes 
chegam ao comutador, eles são colocados no buffer de entrada. O comutador então tenta encaminhar os 
pacotes na frente de cada fila FIFO para sua porta de saída apropriada. Porém, se os pacotes na frente de 
várias portas de entrada diferentes forem destinados para a mesma porta de saída ao mesmo tempo, então 
somente um deles pode ser encaminhado;!º o restante precisa permanecer em seus buffers de entrada. 


!8Para um comutador simples com buffer na entrada, exatamente um pacote de cada vez pode ser enviado para 
determinada porta de saída. É possível projetar comutadores que podem encaminhar mais de um pacote para a mesma saída 
de cada vez, a um custo de uma complexidade mais alta no comutador, mas sempre há algum limite superior sobre o número. 
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FIGURA 3.39 Ilustração simples de bloqueio no início da fila. 
Porta 1 


Porta 2 





Switch 


A desvantagem desse recurso é que aqueles pacotes que ficaram na frente do buffer de entrada impe- 
dem que outros pacotes mais atrás no buffer tenham uma chance de ir até suas saídas correspondentes, 
mesmo que não haja discuta por essas saídas. Esse fenômeno é chamado de bloqueio no início da fila. 
Um exemplo simples de bloqueio no início da fila é mostrado na Figura 3.39, na qual vemos um pacote 
destinado para a porta 1 bloqueado atrás de um pacote disputando pela porta 2. Pode-se mostrar que, 
quando o tráfego é uniformemente distribuído entre as saídas, o bloqueio no início da fila limita a vazão 
de um comutador com buffer de entrada para 59% do máximo teórico (que é a soma das larguras de 
banda de enlace para o comutador). Assim, a maioria dos comutador utiliza ou a bufferização de saída 
pura ou uma combinação de bufferização interna e de saída. Aqueles que de fato contam com buffers 
de entrada utilizam esquemas de gerenciamento de buffer mais avançados para evitar o bloqueio no 
início da fila. 

Os buffers, na verdade, realizam uma tarefa mais complexa do que simplesmente armazenar pacotes 
que estão esperando para ser transmitidos. Os buffers são a principal fonte de atraso em um comutador, 
e também o local onde os pacotes provavelmente serão descartados devido à falta de espaço para arma- 
zená-los. Os buffers, portanto, são o local principal onde as características de qualidade de serviço de 
um comutador são determinadas. Por exemplo, se um certo pacote tiver sido enviado ao longo de um VC 
que possui um atraso garantido, ele não pode ficar em um buffer por muito tempo. Isso significa que os 
buffers, em geral, precisam ser gerenciados usando algoritmos de escalonamento e descarte de pacotes que 
atendam a uma grande faixa de requisitos de QoS. Falaremos mais sobre essas questões no Capítulo 6. 


3.4.3 Malhas 


Embora tenham sido realizadas muitas pesquisas sobre o projeto de malhas eficientes e escaláveis, 
para os nossos propósitos é suficiente entender apenas as propriedades de alto nível de uma malha de 
comutação. Uma malha de comutação deverá ser capaz de mover pacotes das portas de entrada para as 
portas de saída com o mínimo de atraso e de um modo que cumpra os objetivos de vazão do comutador. 
Isso normalmente significa que as malhas apresentam algum grau de paralelismo. Uma malha de alto 
desempenho com n portas normalmente pode mover um pacote de cada uma de suas n portas para 
uma das portas de saída ao mesmo tempo. Alguns tipos de malha incluem os seguintes: 


e Barramento compartilhado - esse é o tipo de “malha” encontrado em um processador convencional 
usado como comutador, conforme descrito anteriormente. Como a largura de banda do barramento 
determina a vazão do comutador, os comutadores de alto desempenho normalmente possuem 
barramentos especialmente projetados, em vez de barramentos padrão encontrados nos PCs. 

e Memória compartilhada- em um comutador de memória compartilhada, os pacotes são escritos 
em um local da memória por uma porta de entrada e depois lidos da memória pelas portas de 
saída. Aqui, é a largura de banda da memória que determina a vazão do comutador, de modo 
que uma memória ampla e rápida normalmente é usada nesse tipo de projeto. Um comutador de 
memória compartilhada é semelhante em princípio ao comutador de barramento compartilhado, 
exceto que ele normalmente usa um barramento de memória especialmente projetado, de alta 
velocidade, ao invés de um barramento de E/S. 

e Crossbar- um comutador crossbar (ou de “barras cruzadas”) consiste em uma matriz de 
caminhos que podem ser configurados para conectar qualquer porta de entrada a qualquer 
porta de saída. A Figura 3.40 mostra um comutador crossbar 4 x 4. O problema principal com os 
comutadores crossbar é que, em sua forma mais simples, eles exigem que cada porta de saída seja 
capaz de aceitar pacotes de todas as entradas ao mesmo tempo, implicando que cada porta teria 
uma memória com largura de banda igual à vazão total do comutador. Na realidade, projetos mais 
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complexos normalmente são usados para resolver essa questão (veja, por exemplo, o comutador 
Knockout e a técnica de buffer de saída virtual de McKeown na seção de Leitura Adicional). 

e Autorroteado — conforme indicamos anteriormente, as malhas autorroteáveis usam alguma 
informação no cabeçalho do pacote para direcionar cada pacote à sua saída correta. 
Normalmente, um “cabeçalho autorroteável” especial é anexado ao pacote pela porta de 
entrada depois que ela tiver determinado para qual saída o pacote precisa ir, conforme 
ilustrado na Figura 3.41; esse cabeçalho extra é removido antes que o pacote saia do switch. 

As malhas autorroteáveis normalmente são construídas a partir de grandes quantidades de 
elementos de comutação 2 x 2 muito simples, interconectados em padrões regulares, como a 
malha de comutação banyan!º mostrada na Figura 3.42. Alguns exemplos de projetos de malha 
autorroteável podem ser vistos na seção de Leitura Adicional ao final deste capítulo. 











FIGURA 3.40 Um comutador crossbar 4 x 4. 
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FIGURA 3.41 Um cabeçalho autorroteável é 
(c) adicionado a um pacote na entrada para permitir 
que a malha envie o pacote para a saída correta, 
Porta de Malha de Porta de onde ele é removido: (a) Pacote chega na porta de 
entrada comutação saída entrada; (b) porta de entrada adiciona cabeçalho 


autorroteável para direcionar pacote à saída 
correta; (c) cabeçalho autorroteável é removido 


Do na porta de saída antes que o pacote saia do 
comutador. 


Este tipo de malha é nomeado em referência à figueira, árvore conhecida como banyan tree em inglês. (N.T.) 
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001 FIGURA 3.42 Roteamento de pacotes por meio de uma rede banyan. Os números 
de 3 bits representam valores nos cabeçalhos autorroteáveis de quatro pacotes 
011 001 que são recebidos. 
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Malhas autorroteáveis estão entre as técnicas mais escaláveis para o projeto de malhas, e tem havido 
muita pesquisa sobre o assunto, parte dela listada na seção de Leitura Adicional. Muitas malhas autor- 
roteáveis são semelhantes àquela mostrada na Figura 3.42, consistindo em elementos de comutação 
2x2 regularmente interconectados. Por exemplo, os comutadores 2 x 2 na rede banyan realizam uma 
tarefa simples: eles examinam 1 bit em cada cabeçalho autorroteável e direcionam os pacotes para a 
saída superior se esse bit for zero ou para a saída inferior se ele for um. Obviamente, se dois pacotes 
chegarem em um elemento de comutação do comutador banyan ao mesmo tempo e em ambos o bit 
tiver o mesmo valor, então eles desejam ser roteados para a mesma saída e haverá uma colisão. Impedir 
ou lidar com essas colisões é um desafio importante no projeto de um comutador autorroteável. A rede 
banyan é um arranjo inteligente dos elementos de comutação 2 x 2, que direciona todos os pacotes para 
a saída correta sem colisões se os pacotes forem apresentados em ordem crescente. 

Podemos ver como isso funciona com um exemplo, como mostra a Figura 3.42, onde o cabeçalho 
autorroteável contém o número da porta de saída codificado em binário. Os elementos de comutação 
na primeira coluna examinam o bit mais significativo do número da porta de saída e direcionam pacotes 
para a parte superior se esse bit for 0 e para a parte inferior se ele for 1. Os elementos de comutação 
na segunda coluna examinam o segundo bit do cabeçalho, e aqueles na última coluna examinam o 
bit menos significativo. Você pode ver, por esse exemplo, que os pacotes são roteados para a porta de 
destino correta sem colisões. Observe como as saídas mais ao alto da primeira coluna de elementos de 
comutação são conectadas à metade superior da rede banyan, levando assim os pacotes com números 
de porta de 0 a 3 para a metade correta da rede. A coluna seguinte leva os pacotes para a quarta parte 
(metade da metade) correta da rede, e a última coluna os leva para a porta de saída correta. O compo- 
nente inteligente é o modo como os elementos de comutação são arranjados para evitar colisões. Parte 
do arranjo inclui o padrão de organização dos fios do tipo “embaralhamento perfeito” no início da rede. 
Para construir uma malha de comutação completa em torno de uma rede banyan, seria preciso haver 
componentes adicionais para classificar pacotes antes que eles fossem apresentados à rede banyan. 
A estrutura dos comutadores Batcher-banyan é um exemplo notável dessa técnica. A rede Batcher, 
que também é construída a partir de uma interconexão normal de elementos de comutação 2 x 2, 
classifica os pacotes em ordem decrescente. Ao sair da rede Batcher, os pacotes estão prontos para ser 
redirecionados para a saída correta, sem risco de colisões, pela rede banyan. 

Uma das coisas interessantes sobre o projeto de comutadores é a grande gama de diferentes tipos 
de comutadores que podem ser construídos usando a mesma tecnologia básica. Por exemplo, switches 
Ethernet, switches ATM e roteadores da Internet, discutidos a seguir, foram todos montados usando 
projetos como aqueles esboçados nesta seção. 


3.4.4 Implementação de roteadores 


Até aqui, já vimos diversas maneiras de montar um comutador, variando desde um processador de uso 
geral com um número adequado de interfaces de rede até alguns projetos de hardware sofisticados. Em 
geral, a mesma gama de opções está disponível para montar roteadores, muitos dos quais apresentam 
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FIGURA 3.43 Digrama de blocos 
Processador de um roteador. 
de controle 
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uma estrutura semelhante àquela mostrada na Figura 3.43. O processador de controle é responsável 
por executar os protocolos de roteamento discutidos anteriormente, entre outras coisas, e geralmente 
atua como ponto de controle central do roteador. A malha de comutação transfere pacotes de uma porta 
para outra, assim como em um switch; e as portas oferecem diversas funcionalidades para permitir que 
o roteador se comunique com enlaces de diversos tipos (por exemplo, Ethernet e SONET). 

Alguns pontos precisam ser observados sobre o projeto do roteador e como ele difere do projeto de 
switches. Primeiro, os roteadores precisam ser projetados para lidar com pacotes de tamanho variável, 
uma restrição que não se aplica a switches ATM, mas certamente é aplicável a switches Ethernet ou 
Frame Relay. Acontece que muitos roteadores de alto desempenho são projetados usando uma malha 
de comutação que é baseada em células. Nesses casos, as portas precisam ser capazes de converter 
pacotes de tamanho variável em células e vice-versa. Isso é conhecido como segmentação e remontagem 
(SAR — Segmentation And Re-assembly), um problema também enfrentado por adaptadores de rede 
para redes ATM. 

Outra consequência do tamanho variável dos datagramas IP é que pode ser mais difícil caracterizar 
o desempenho de um roteador do que o de um switch que encaminha apenas células. Os roteadores 
normalmente podem encaminhar um certo número de pacotes por segundo, e isso implica que o vazão 
total em bits por segundo depende do tamanho do pacote. Os projetistas de roteadores geralmente 
precisam fazer uma escolha sobre o tamanho de pacote que eles aceitarão em termos de taxa de trans- 
ferência de linha. Ou seja, se pps (pacotes por segundo) for a taxa em que os pacotes chegando a 
determinada porta podem ser encaminhados, e taxadelinha é a velocidade física da porta em bits por 
segundo, então existe algum tamanhopacote em bits tal que: 


tamanhopacote x pps = taxadelinha 


Esse é o tamanho de pacote que o roteador é capaz de encaminhar na taxa de transferência de 
linha; ele provavelmente poderá sustentar a taxa de transferência de linha para pacotes maiores, mas 
não para pacotes menores. Às vezes, um projetista pode decidir que o tamanho de pacote correto a ser 
suportado é 40 bytes, pois esse é o tamanho mínimo de um pacote IP que carrega um cabeçalho TCP 
Outra escolha poderia ser o tamanho de pacote médio esperado, que pode ser determinado estudando 
registros de tráfego de rede. Por exemplo, as medições do backbone da Internet sugerem que o pacote 
IP médio tem em torno de 300 bytes de extensão. Porém, esse roteador apresentaria baixo desempenho 
e talvez começasse a descartar pacotes quando enfrentasse uma longa sequência de pacotes curtos, o 
que é estatisticamente provável de vez em quando e também muito possível se o roteador for alvo de 
um ataque ativo (ver Capítulo 8). As decisões de projeto desse tipo dependem muito das considerações 
de custo e da aplicação alvo do roteador. 

Quando se trata da tarefa de encaminhar pacotes IP os roteadores podem ser caracterizados de 
modo geral como tendo um modelo de encaminhamento centralizado ou distribuído. No modelo 
centralizado, o algoritmo de encaminhamento IP esboçado anteriormente neste capítulo, é feito em 
um único elemento de processamento que trata o tráfego de todas as portas. No modelo distribuído, 
existem vários elementos de processamento, talvez um por porta, ou mais frequentemente um por 
placa de linha, onde uma placa de linha pode servir a uma ou mais portas físicas. Cada modelo tem suas 
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vantagens e desvantagens. Em condições normais, um modelo de encaminhamento distribuído deverá 
ser capaz de encaminhar mais pacotes por segundo por meio do roteador como um todo, pois existe 
mais poder de processamento no total. Mas um modelo distribuído também complica a arquitetura 
de software, pois cada mecanismo de encaminhamento normalmente precisa de sua própria cópia da 
tabela de encaminhamento, e por isso é necessário que o processador de controle garanta que as tabelas 
de encaminhamento sejam atualizadas de modo consistente e a tempo. 

Outro aspecto da implementação de roteadores que é significativamente diferente daquele dos 
switches é o próprio algoritmo de encaminhamento IP. Em bridges e na maioria dos switches ATM, o 
algoritmo de encaminhamento simplesmente envolve a busca por um identificador de tamanho fixo 
(endereço MAC ou VCI) em uma tabela, encontrar a porta de saída correta na tabela e enviar o pacote 
para essa porta. Já vimos, na Seção 3.2.4, que o algoritmo de encaminhamento do IP é um pouco mais 
complicado do que isso, em parte porque o número relevante de bits que precisa ser examinado ao 
encaminhar um pacote não é fixo, mas variável, normalmente na faixa de 8 bits a 32 bits. 

Devido à complexidade relativamente alta do algoritmo de encaminhamento IP houve períodos 
na história em que parecia que os roteadores IP poderiam estar atrapalhando a obtenção de limites 
superiores fundamentais de desempenho. Porém, conforme discutimos na seção de Leitura Adicional 
deste capítulo, foram desenvolvidas muitas abordagens inovadoras para encaminhamento de pacotes 
IP no decorrer dos anos, e no momento em que este livro foi escrito, existem roteadores comerciais 
que podem encaminhar 40 Gbps de tráfego IP por interface. Combinando muitos desses mecanismos 
de encaminhamento IP de alto desempenho com o tipo de malha de comutação altamente escalável 
discutido na Seção 3.4, agora é possível construir roteadores com muitos terabits de vazão total. Isso é 
mais do que suficiente para levarmos a cabo os próximos anos de crescimento de tráfego da Internet. 

Outra tecnologia de interesse no que se refere à implementação de roteadores é o processador de 
rede. Um processador de rede tem a finalidade de ser um dispositivo aproximadamente tão programável 
quanto um processador de um computador pessoal padrão, mas que é otimizado mais especificamente 
para tarefas de rede. Por exemplo, um processador de rede poderia ter instruções que sejam particu- 
larmente bem adequadas para realizar buscas de endereços IP ou calcular somas de verificação sobre 
datagramas IP. Esses dispositivos poderiam ser usados em roteadores e outros dispositivos de rede 
(como firewalls). 

Um dos debates interessantes e contínuos sobre processadores de rede é se eles podem realizar 
um trabalho melhor do que as alternativas aos mesmos. Por exemplo, dadas as melhorias contínuas e 
marcantes no desempenho de processadores convencionais, e a imensa indústria que movimenta essas 
melhorias, os processadores de rede seriam capazes de acompanhar tais avanços? E seria possível que 
um dispositivo que luta para ser genérico seja capaz de realizar um trabalho tão bom quanto um circuito 
integrado para uma aplicação específica (ASIC — Application-Specific Integrated Circuit), com projeto 
personalizado, que não faz nada exceto, digamos, encaminhamento IP? Parte da resposta para perguntas 
como estas depende do que você quer dizer com “fazer um trabalho melhor”. Por exemplo, sempre haverá 
escolhas a serem feitas entre custo de hardware, tempo de entrada no mercado, desempenho, consumo 
de energia e flexibilidade — a capacidade de alterar as funcionalidades suportadas por um roteador 
após ele ser construído. Veremos, nos próximos capítulos, como os requisitos de funcionalidades do 
roteador podem ser diversificados. É seguro considerar que haverá uma grande variedade de projetos 
de roteadores durante o futuro próximo e que os processadores de rede desempenharão algum papel 
nesse contexto. 


3.5 Resumo 


Este capítulo começou a examinar algumas das questões envolvidas na montagem de redes escaláveis 
e heterogêneas usando switches e roteadores para interconectar enlaces e redes. O uso mais comum da 
comutação é a interconexão de LANS, especialmente segmentos Ethernet. Switches de LAN, ou bridges, 
utilizam técnicas como aprendizado do endereço de origem para melhorar a eficiência do encami- 
nhamento e algoritmos de spanning tree para evitar encaminhamento em círculos. Esses switches são 
muito utilizados em centros de dados, campi e redes corporativas. 
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Para lidar com redes heterogêneas, o Internet Protocol (IP) foi inventado e constitui a base dos rotea- 
dores de hoje. O IP enfrenta a heterogeneidade definindo um modelo de serviço simples e comum para 
uma inter-rede, que é baseado na entrega de melhor esforço de datagramas IP Uma parte importante 
do modelo de serviço é o esquema de endereçamento global, que permite a dois nós quaisquer em uma 
inter-rede identificarem univocamente uns aos outros para fins de troca de dados. O modelo de serviço 
IP é simples o suficiente para ser suportado por qualquer tecnologia de rede conhecida, e o mecanismo 
ARP é usado para traduzir endereços globais em endereços locais da camada de enlace. 

Um aspecto crucial da operação de uma inter-rede é a determinação de rotas eficientes para qualquer 
destino na inter-rede. Os algoritmos de roteamento de inter-rede resolvem o problema de uma forma 
distribuída; este capítulo introduziu duas classes principais de algoritmos — estado do enlace e vetor de 
distâncias -, juntamente com exemplos de sua aplicação (RIP e OSPF). 

Tanto switches quanto roteadores precisam encaminhar pacotes de entradas para saídas com uma 
alta velocidade e, em algumas circunstâncias, crescer até atingir um tamanho grande o suficiente para 
acomodar centenas ou milhares de portas. A construção de switches que sejam ao mesmo tempo es- 
caláveis e forneçam alto desempenho a um custo aceitável é complicada pelo problema de disputas 
por recursos (portas e buffers). Como consequência, switches e roteadores normalmente empregam 
hardware específico em vez de serem construídos a partir de estações de trabalho de uso geral. 


E E O que vem em seguida: “a Internet do futuro” E 


A Internet sem dúvida tem sido um enorme sucesso, e pode ser fácil esquecer que já houve uma 
época em que ela não existia. Porém, os inventores da Internet a desenvolveram em parte porque 
as redes disponíveis na época, como a rede telefônica com comutação de circuitos, não eram muito 
adequadas para as coisas que eles queriam fazer. Agora que a Internet é um artefato bem estabelecido, 
como era a rede telefônica na década de 1960, é razoável perguntar: O que virá depois da Internet? 

Ninguém sabe a resposta para essa pergunta no momento, mas alguns esforços de pesquisa 
significativos estão sendo feitos para tentar permitir a construção de uma espécie de “Internet do 
futuro”. Embora seja difícil imaginar que a Internet de hoje será substituída por algo novo em pouco 
tempo (afinal, a rede telefônica ainda existe, embora cada vez mais seu tráfego esteja sendo trans- 
ferido para a Internet), pensar além das restrições de ajustes de implementação incrementais na 
Internet de hoje poderia permitir algumas inovações que, de outra forma, não ocorreriam. É comum 
pensar a respeito de uma pesquisa “do zero” nesse contexto — essa pesquisa se concentraria no que 
poderia ser possível se pudéssemos começar do zero, deixando as considerações de implantação 
para depois. 

Por exemplo, e se assumíssemos que cada nó da Internet fosse móvel? Provavelmente, come- 
çaríamos com um modo diferente de identificar os nós, em vez de endereços IP - que incluem 
informações sobre em que rede o nó está atualmente conectado —, poderíamos usar alguma outra 
forma de identificador. Ou, como outro exemplo, poderíamos considerar um modelo de confiança 
diferente daquele que existe na Internet atual. Quando a Internet foi desenvolvida originalmente, 
parecia razoável considerar que cada host fosse capaz de enviar dados para qualquer outro host por 
padrão, mas hoje, no mundo dos spammers, phishers e ataques de negação de serviço, um modelo de 
confiança diferente — talvez com capacidades iniciais mais limitadas para nós recém-conectados ou 
desconhecidos — poderia ser considerado. Esses dois exemplos ilustram casos em que, sabendo hoje 
de algumas coisas que não eram evidentes na década de 1970 (como a importância da mobilidade e 
da segurança nas redes), poderíamos chegar a um projeto muito diferente para uma inter-rede. 

Podemos chegar a algumas conclusões aqui. Primeiro, você não deve considerar que a Internet 
está “pronta”. Sua arquitetura é inerentemente flexível e ela continuará a evoluir. Veremos alguns 
exemplos de sua evolução no próximo capítulo. O outro ponto é que há mais de uma maneira de 
pesquisar sobre redes: desenvolver ideias implementáveis de forma incremental é ótimo, mas, nas 
palavras do pioneiro da Internet David Clark: “Para conceber o futuro, é importante abrir mão do 
presente”. 
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Leitura adicional 


O artigo pioneiro sobre bridges, particularmente o algoritmo de spanning tree, é o artigo de Perlman a seguir. Não é sur- 

presa que inúmeros artigos tenham sido escritos sobre diversos aspectos da Internet; o artigo de Cerf e Kahn é aquele 

que introduziu originalmente a arquitetura TCP/IP e merece ser lido por sua perspectiva histórica. Por fim, o artigo de 

McKeown, um dos muitos sobre projeto de switches, descreve uma técnica para projetos de switches que usam células 

internamente, mas tem sido usado comercialmente como a base para roteadores de alto desempenho que encaminham 

pacotes IP de tamanhos variáveis. 

Perlman, R. An algorithm for distributed computation of spanning trees in an extended LAN. Proceedings of the Ninth 
Data Communications Symposium, p. 44-53, setembro de 1985. 

Cerf, V.; Kahn, R. A protocol for packet network intercommunication. IEEE Transactions on Communications COM, v. 22, 
n. 5, p. 637-48, maio de 1974. 

McKeown, N. The iSLIP scheduling algorithm for input-queued switches. IEEE Transactions on Networking, v. 7, n. 2, p. 
188-201, abril de 1999. 


Uma boa visão geral sobre bridges e roteadores pode ser encontrada em outro trabalho de Perlman 
[Per00]. Existem diversos artigos sobre ATM; Turner [Tur85], um pioneiro em ATM, foi um dos primeiros 
a propor o uso de uma rede baseada em células para serviços integrados. 

Muitas das técnicas e protocolos que são fundamentais para a Internet de hoje são descritos em 
Requests For Comments (RFCs): as sub-redes são descritas em Mogul e Postel [MP85], CIDR é des- 
crito em Fuller e Li [FL06], RIPv2 é definido em Malkin [Mal98], e OSPF é definido em Moy [Moy98]. 
A especificação do OSPF, com mais de 200 páginas, é um dos RFCs mais longos, mas contém uma 
riqueza de detalhes incomum a respeito de como implementar um protocolo. Os motivos para evitar 
a fragmentação no IP são examinados em Kent e Mogul [KM87] e a técnica de descoberta de MTU do 
caminho é descrita em Mogul e Deering [MD90]. 

Um artigo visionário com uma pesquisa sobre a Internet do futuro foi escrito por Clark e outros 
[CPB+05]. Esse artigo está relacionado aos esforços de pesquisa contínuos em torno da Internet do 
futuro, para a qual oferecemos referências vivas mais adiante. 

Literalmente milhares de artigos foram publicados sobre arquiteturas de switch. Um artigo inicial 
que explica muito bem sobre as redes de Batcher é, logicamente, um do próprio Batcher [Bat68]. A 
classificação de redes é explicada por Drysdale e Young [DY75], e uma forma interessante de switch 
crossbar é descrita por Yeh et al. [YHA87]. Giacopelli et al. [G6HMS91] descrevem o switch “Sunshine”, que 
oferece ideias para um papel importante da análise de tráfego no projeto de switches. Em particular, os 
projetistas do Sunshine estavam entre os primeiros a observar que as células provavelmente chegariam 
em um switch em rajadas e, portanto, foram capazes de incluir chegadas correlacionadas como um 
fator em seu projeto. Uma boa visão geral do desempenho de diferentes malhas de comutação pode 
ser encontrada em Robertazzi [Rob93]. Um exemplo do projeto de um switch baseado em pacotes de 
tamanho variável pode ser encontrado em Gopal e Guerin [6G94]. 

Tem havido muito trabalho voltado para o desenvolvimento de algoritmos que podem ser usados por 
roteadores para realizar uma busca rápida de endereços IP. (Lembre que o problema é que o roteador 
precisa achar a correspondência com o prefixo mais longo na tabela de encaminhamento.) Árvores 
PATRICIA estão entre os primeiros algoritmos aplicados para esse problema [Mor68]. Trabalhos mais 
recentes são descritos em [DBCP97], [WVTP97], [LS98], [SVSM98] e [EVD04]. Para ter uma visão geral de 
como algoritmos como estes podem ser usados para montar um roteador de alta velocidade, consulte 
Partridge et al. [Par98]. 

Redes ópticas é um campo rico por si só, com seus próprios periódicos, conferências etc. Recomen- 
damos Ramaswami et al. [RS01] como um bom texto introdutório nesse campo. 

Um excelente texto para ser lido se você quiser aprender sobre a análise matemática do desempe- 
nho de redes é o de Kleinrock [Kle75], um dos pioneiros da ARPANET. Muitos artigos foram publicados 
sobre as aplicações da teoria de filas na comutação de pacotes. Recomendamos o artigo de Paxson e 
Floyd [PF94] como uma contribuição significativa voltada para a Internet, e Leland et al. [LTWW94], um 
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artigo que introduz o importante conceito de “dependência de longo alcance” e mostra a inadequação 
de muitas abordagens tradicionais de modelagem de tráfego. 


Finalmente, recomendamos as seguintes referências vivas: 


http://www.nets-find.net/: Um site da U.S. National Science Foundation a respeito do programa 
de pesquisa “Projeto da Internet do Futuro”. 

http://www.geni.net/: Um site descrevendo o banco de testes de rede GENI, que foi criado para 
permitir parte da pesquisa “do zero”, descrita anteriormente.Exercícios 


. Usando a rede de exemplo dada na Figura 3.44, crie as tabelas de circuito virtual para todos os 


switches após cada uma das seguintes conexões ser estabelecida. Suponha que a sequência de 
conexões é cumulativa; ou seja, a primeira conexão ainda está ativa quando a segunda conexão 
é estabelecida, e assim por diante. Considere também que a atribuição de VCI sempre seleciona 
o VCI não usado mais baixo em cada enlace, começando com 0, e que um VCI é consumido para 
ambas as direções de um circuito virtual. 

Host A conecta-se ao host C. 

Host D conecta-se ao host B. 

Host D conecta-se ao host I. 

Host A conecta-se ao host B. 

Host F conecta-se ao host J. 

- Host H conecta-se ao host A. 

Usando a rede de exemplo dada na Figura 3.44, crie as tabelas de circuito virtual para todos os 
switches após cada uma das seguintes conexões ser estabelecida. Suponha que a sequência de 
conexões é cumulativa; ou seja, a primeira conexão ainda está ativa quando a segunda conexão 
é estabelecida, e assim por diante. Considere também que a atribuição de VCI sempre seleciona 
o VCI não usado mais baixo em cada enlace, começando com 0, e que um VCI é consumido para 
ambas as direções de um circuito virtual. 

a. Host D conecta-se ao host H. 

b. Host B conecta-se ao host G. 

c. Host F conecta-se ao host A. 

d. Host H conecta-se ao host C. 


*penDo 






Host E 





FIGURA 3.44 Rede de exemplo para os Exercícios 1 e 2. 
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e. Host I conecta-se ao host E. 

f. Host H conecta-se ao host. 

3. Para a rede mostrada na Figura 3.45, crie a tabela de encaminhamento de datagramas para cada 
nó. Os enlaces são rotulados com custos relativos; suas tabelas deverão encaminhar cada pacote 
por meio do caminho de menor custo até o seu destino. 

4. Monte as tabelas de encaminhamento para os switches de S1 a S4 na Figura 3.46. Cada switch 
deverá ter uma entrada de roteamento padrão, escolhida de forma a encaminhar pacotes com 
endereços de destino não reconhecidos na direção de OUT. Quaisquer entradas de tabela 
com destino específico que sejam redundantes em razão da entrada padrão deverão então ser 
eliminadas. 

5. Considere os switches de circuito virtual na Figura 3.47. A Tabela 3.15 lista, para cada switch, 
quais pares (porta, VCI} (ou (VCI, interface)) estão conectados a qual outro. As conexões são 
bidirecionais. Liste todas as conexões de uma extremidade à outra. 

6. No exemplo de roteamento na origem da Seção 3.1.3, o endereço recebido por B não é reversível e 
não ajuda B a saber como alcançar A. Proponha uma modificação no mecanismo de entrega que 
permita a reversibilidade. Seu mecanismo não deverá exigir nomes globalmente exclusivos para 
todos os switches. 


(A) 3 (6) 








6 
© o 
2 | 2 2 2 
1 3 1 3 1 3 1 
S1 S2 S3 S4 
FIGURA 3.45 Rede para o Exercício 3. FIGURA 3.46 Diagrama para o Exercício 4. 











2 


1 3 1 3 1 3 
S1 S2 s3 
FIGURA 3.47 Diagrama para o Exercício 5. 





Tabela 3.15 Tabelas para switches da Figura 3.47 




















Switch S1 

Porta VCI Porta VCI 
1 2 3 1 

íl 1 2 3 

2 1 3 2 
Switch S2 

Porta VCI Porta VCI 
1 1 3 3 

1 2 3 2 
Switch S3 

Porta VCI Porta VCI 


1 3 2 1 
1 2 2 2 
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10. 


11. 


12. 


13. 


(14. 


15. 


(0; 


Proponha um mecanismo que os switches de circuito virtual possam usar de modo que, se 

um switch perder toda a sua informação de estado relativo às conexões, então um emissor de 

pacotes ao longo do caminho até esse switch seja informado da falha. 

Proponha um mecanismo que possa ser usado por switches de datagrama de modo que, se um 

switch perder toda ou parte de sua tabela de encaminhamento, os emissores afetados sejam 

informados da falha. 

O mecanismo de circuitos virtuais descrito na Seção 3.1.2 considera que cada enlace é ponto 

a ponto. Estenda o algoritmo de encaminhamento para que ele funcione no caso em que os 

enlaces são conexões de meio compartilhado (por exemplo, Ethernet). 

Suponha na Figura 3.2, que um novo enlace tenha sido acrescentado, conectando a porta 1 

do switch 3 (onde agora está G) e a porta 0 do switch 1 (onde agora está D); nenhum switch 

é informado desse enlace. Além disso, o switch 3 por engano pensa que o host B pode ser 

alcançado pela porta 1. 

a. O que acontece se o host A tenta enviar dados para o host B, usando o encaminhamento de 
datagramas? 

b. O que acontece se o host A tenta se conectar ao host B, usando o mecanismo de 
estabelecimento de circuito virtual discutido no texto? 

Dê um exemplo de um circuito virtual funcional cujo caminho atravesse algum enlace 

duas vezes. Os pacotes enviados ao longo desse caminho, porém, não deverão circular 

indefinidamente. 

Na Seção 3.1.2, cada switch escolheu o valor de VCI para o enlace de chegada. Mostre que 

também é possível que cada switch escolha o valor de VCI para o enlace de saída e que os 

mesmos valores de VCI sejam escolhidos por cada técnica. Se cada switch escolher o VCI de 

saída, também é preciso esperar um RTT antes que os dados sejam enviados? 

Dada a LAN estendida que aparece na Figura 3.48, indique quais portas não são selecionadas 

pelo algoritmo de spanning tree. 

Dada a LAN estendida mostrada na Figura 3.48, suponha que a bridge B1 sofra uma falha 

catastrófica. Indique quais portas não são selecionadas pelo algoritmo de spanning tree após o 

processo de recuperação e uma nova árvore tiver sido formada. 

Considere o arranjo de bridges com aprendizado mostrado na Figura 3.49. Supondo que todas 

estejam inicialmente vazias, forneça as tabelas de encaminhamento para cada uma das bridges 

de B1 a B4 após as seguintes transmissões: 

e A envia dados para C. 

e C envia dados para A. 

e D envia dados para C. 


E | 
| O 
OO 


N 
o 


J 
SO FIGURA 3.49 Rede para 
FIGURA 3.48 Rede para os Exercícios 13 e 14. os Exercícios 15 e 16. 
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Identifique as portas com o único vizinho alcançado diretamente a partir dessa porta; ou seja, as 
portas de B1 são rotuladas como “A” e “B2”. 
16. Assim como no problema anterior, considere o arranjo das seguintes bridges mostradas 
na Figura 3.49. Considerando que todas estejam inicialmente vazias, forneça as tabelas de 
encaminhamento para cada uma das bridges de B1 a B4 após as seguintes transmissões: 
e D envia dados para C. 
e C envia dados para D. 
e A envia dados para C. 
17. Considere os hosts X, Y, Z, W e as bridges com aprendizado B1, B2, B3, com tabelas de 
encaminhamento inicialmente vazias, como na Figura 3.50. 
a. Suponha que X envie dados para W. Quais bridges descobrem onde X está? A interface de rede 
de Y vê esse pacote? 
b. Suponha que Z agora envie dados para X. Quais bridges descobrem onde Z está? A interface 
de rede de Y vê esse pacote? 
c. Suponha que Y agora envie dados para X. Quais bridges descobrem onde Y está? A interface de 
rede de Z vê esse pacote? 
d. Por fim, suponha que W envie dados para Y. Quais bridges descobrem onde W está? A 
interface de rede de Z vê esse pacote? 
18. Forneça a spanning tree gerada para a LAN estendida mostrada na Figura 3.51, e discuta como 
situações de empate são resolvidos. 
19. Suponha que as bridges com aprendizado B1 e B2 formem um ciclo, conforme mostra a 
Figura 3.52, e não implementem o algoritmo de spanning tree. Cada bridge mantém uma única 
tabela de pares (endereço, interface). 
a. O que acontecerá se M enviar dados para L? 
b. Suponha que, pouco depois, L responda para M. Forneça uma sequência de eventos que leve 
um pacote de M e um pacote de L a circularem pelo ciclo em sentidos opostos. 
20. Suponha que M na Figura 3.52 envie dados para si mesmo (isso normalmente nunca 
aconteceria). Indique o que aconteceria, supondo que: 
a. O algoritmo de aprendizagem das bridges deve adicionar (ou atualizar) a nova entrada 
(endereço. origem, interface) antes de buscar o endereço de destino na tabela. 
b. O novo endereço de origem é adicionado depois da busca pelo endereço de destino. 
21. Considere a LAN estendida da Figura 3.10. O que acontece no algoritmo de spanning tree se a 
bridge B1 não participar e 
a. Simplesmente encaminhar todas as mensagens do algoritmo de spanning tree? 
b. Descartar todas as mensagens de spanning tree? 
22. Suponha que alguns repetidores (hubs), em vez de bridges, estejam conectados a um ciclo. 
a. O que acontecerá quando alguém transmitir? 
b. Por que o mecanismo de spanning tree seria difícil ou impossível de ser implementado para 
os repetidores? 
c. Proponha um mecanismo pelo qual os repetidores poderiam detectar ciclos e desativar 
algumas portas para quebrar o ciclo. Sua solução não precisa funcionar 100% do tempo. 





6 SoM a 


FIGURA 3.50 Diagrama FIGURA 3.51 LAN estendida FIGURA 3.52 Rede com ciclo 
para o Exercício 17. para o Exercício 18. para os Exercícios 19 e 20. 
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Suponha que uma bridge tenha duas de suas portas na mesma rede. Como a bridge poderia 
detectar e corrigir isso? 

Que porcentagem da largura de banda total de um enlace ATM é consumida pelos cabeçalhos 
das células ATM? Ignore o preenchimento de células ou cabeçalhos da camada de adaptação do 
ATM. 

Os métodos de comutação de célula (como o ATM) basicamente sempre usam a comutação de 
circuitos virtuais ao invés do encaminhamento de datagrama. Dê um argumento específico por 
que isso acontece (considere a pergunta anterior). 

Suponha que uma estação de trabalho tenha um barramento de E/S cuja velocidade é 800 Mbps 
e cuja memória tenha uma largura de banda de 2 Gbps. Supondo que o acesso direto à memória 
(DMA) seja usado para mover dados para dentro e para fora da memória principal, quantas 
interfaces para enlaces Ethernet de 100 Mbps um switch baseado nessa estação de trabalho 
poderia tratar? 

Suponha que uma estação de trabalho tenha barramento de E/S cuja velocidade é 1 Gbps e cuja 
memória tenha uma largura de banda de 2 Gbps. Supondo que o DMA seja usado para mover 
dados para dentro e para fora da memória principal, quantas interfaces para enlaces Ethernet de 
100 Mbps um switch baseado nessa estação de trabalho poderia tratar? 

Suponha que um switch seja construído usando uma estação de trabalho e que ele possa 
encaminhar pacotes a uma velocidade de 500.000 pacotes por segundo, independente do seu 
tamanho (dentro dos limites). Suponha que a estação de trabalho use acesso direto à memória 
(DMA) para mover dados para dentro e para fora de sua memória principal, que tenha uma 
largura de banda de 2 Gbps e que o barramento de E/S tenha uma largura de banda de 1 Gbps. 
Em que tamanho de pacote a largura de banda do barramento se tornaria o fator limitador? 
Suponha que um switch seja projetado para realizar buferização FIFO tanto na entrada como na 
saída. À medida que os pacotes chegam em uma porta de entrada, eles são inseridos no final da 
fila FIFO. O switch, então, tenta encaminhar os pacotes no início de cada fila FIFO para o final da 
fila FIFO de saída apropriada. 

a. Explique sob quais circunstâncias esse switch pode perder um pacote destinado a uma porta 
de saída cuja fila FIFO esteja vazia. 

b. Como é chamado esse comportamento? 

c. Considere que a memória de bufferização FIFO possa ser redistribuída livremente. Sugira 
um reembaralhamento dos buffers que evite o problema anterior e explique por que isso 
acontece. 

Um estágio de uma rede banyan n x n consiste em (n/2) elementos de comutação 2 x 2. O 
primeiro estágio direciona os pacotes para a metade correta da rede, o próximo estágio para a 
quarta parte correta, e assim por diante, até que o pacote seja direcionado para a saída correta. 
Derive uma expressão para o número de elementos de comutação 2 x 2 necessários para criar 
uma rede banyan n x n. Verifique sua resposta para n=8. 

Descreva como funciona uma rede de Batcher. (Veja a seção de Leitura Adicional.) Explique 
como uma rede de Batcher pode ser usada em combinação com uma rede banyan para construir 
uma malha de comutação. 

Suponha que um hub (repetidor) Ethernet de 10 Mbps seja substituído por um switch de 10 
Mbps, em um ambiente onde todo o tráfego é feito entre um único servidor e N “clientes”. Como 
todo o tráfego ainda precisa atravessar o enlace servidor-switch, nominalmente não existe 
melhoria na largura de banda. 

a. Você esperaria qualquer melhoria na largura de banda? Nesse caso, por quê? 

b. Que outras vantagens e desvantagens um switch poderia oferecer em relação a um hub? 

Que aspecto dos endereços IP torna necessário ter um endereço por interface de rede, em vez 
de apenas um por host? Com base na sua resposta, por que o IP tolera interfaces ponto a ponto 
que possuem endereços não exclusivos ou nenhum endereço? 

Por que o campo Deslocamento no cabeçalho IP mede o deslocamento em unidades de 8 bytes? 
(Dica: Lembre que o campo Deslocamento tem 13 bits de extensão.) 
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Alguns erros de sinalização podem fazer com que intervalos inteiros de bits em um pacote sejam 
substituídos por apenas 0s ou apenas 1s. Suponha que todos os bits no pacote, incluindo a soma 
de verificação da Internet, sejam modificados. Um pacote com apenas Os ou 1s poderia ser um 
pacote IPv4 válido? A soma de verificação da Internet detectaria esse erro? Por que? 

Suponha que uma mensagem TCP contendo 1024 bytes de dados e 20 bytes de cabeçalho TCP 
seja passada ao IP para entrega por duas redes interconectadas por um roteador (ou seja, ela 

viaja do host de origem até um roteador e então para o host de destino). A primeira rede tem 
uma MTU de 1024 bytes; a segunda tem uma MTU de 576 bytes. A MTU de cada rede determina 
o tamanho do maior datagrama IP que pode ser transportado em um quadro da camada de 
enlace. Indique os tamanhos e deslocamentos da sequência de fragmentos entregues à camada 
de rede no host de destino. Considere que todos os cabeçalhos IP têm 20 bytes. 

A MTU do caminho corresponde à menor MTU de qualquer enlace no caminho (rota) atual entre 
dois hosts. Suponha que possamos descobrir a MTU do caminho usado no exercício anterior, e 
que usemos esse valor como a MTU para todos os segmentos do caminho. Mostre os tamanhos e 
deslocamentos da sequência de fragmentos entregues à camada de rede no host de destino. 
Suponha que um pacote IP seja fragmentado em 10 fragmentos, cada um com uma 
probabilidade de perda (independente) de 1%. Para uma aproximação razoável, isso significa 
que existe uma chance de 10% de perder o pacote inteiro devido à perda de um fragmento. Qual 
é a probabilidade de perda líquida do pacote inteiro se o pacote for transmitido duas vezes, 

a. Supondo que todos os fragmentos recebidos devem ter sido parte da mesma transmissão? 

b. Supondo que qualquer fragmento pode ter sido parte de qualquer transmissão? 

c. Explique como o uso do campo Ident poderia ser aplicável aqui. 

Suponha que todos os fragmentos da Figura 3.18(b) passem por outro roteador em um enlace com 
uma MTU de 380 bytes, sem contar com o cabeçalho do enlace. Mostre os fragmentos produzidos. Se 
o pacote fosse fragmentado originalmente para essa MTU, quantos fragmentos seriam produzidos? 
Qual é a largura de banda máxima em que um host IP pode enviar pacotes de 576 bytes sem 

que o valor do campo Ident seja ciclicamente reiniciado dentro de 60 segundos? Suponha que 

o tempo de vida máximo do segmento (maximum segment lifetime -- MSL) do IP seja de 60 
segundos; ou seja, os pacotes adiados podem chegar até 60 segundos atrasados, mas não mais 
do que isso. O que poderia acontecer se essa largura de banda fosse excedida? 

Por que você acha que o IPv4 efetua a remontagem dos fragmentos no destino final, em vez 

de fazê-lo no próximo roteador? Por que você acha que o IPv6 abandonou totalmente a 
fragmentação? (Dica: Pense nas diferenças entre a fragmentação da camada IP e a fragmentação 
da camada de enlace.) 

Fazer com que as entradas da tabela ARP expirem seu tempo limite após 10 a 15 minutos é uma 
tentativa que apresenta um compromisso razoável. Descreva os problemas que podem ocorrer 
se o valor do tempo de expiração for muito pequeno ou muito grande. 

O IP atualmente usa endereços de 32 bits. Se pudéssemos reprojetar o IP para usar um endereço 
MAC de 6 bytes em vez do endereço de 32 bits, poderíamos eliminar a necessidade do ARP? 
Explique por quê. 

Suponha que os hosts A e B tenham recebido o mesmo endereço IP na mesma Ethernet, na qual 
o ARP é utilizado. B é inicializado depois de A. O que acontecerá com as conexões existentes 

de A? Explique como o “ARP automático” (consultar a rede sobre o seu próprio endereço IP na 
inicialização) poderia ajudar com esse problema. 

Suponha que uma implementação IP execute literalmente o seguinte algoritmo no recebimento 
de um pacote, P destinado para o endereço IP D: 


se (<endereço Ethernet para D está no cache ARP>) 
<envia P> 

senão 
<envia uma consulta ARP para D> 
<coloca P em uma fila até a resposta retornar 


a. Se a camada IP receber uma rajada de pacotes destinados a D, como esse algoritmo poderia 
desperdiçar recursos desnecessariamente? 
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47. 


48. 
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52. 





b. Esboce uma versão melhorada. 

c. Suponha que simplesmente descartemos P depois de enviar uma consulta, quando a busca 
em cache falha. Como isso funcionaria? (Algumas implementações ARP iniciais supostamente 
faziam isso.) 

Para a rede mostrada na Figura 3.53, mostre as tabelas globais de vetor de distâncias como 

aquelas mostradas nas Tabelas 3.10 e 3.13 quando 

a. Cada nó conhece apenas as distâncias até seus vizinhos imediatos. 

b. Cada nó enviou a informação que tinha na etapa anterior aos seus vizinhos imediatos. 

c. Aetapa (b) acontece pela segunda vez. 

Para a rede dada na Figura 3.54, mostre as tabelas globais de vetor de distâncias como aquelas 
mostradas nas Tabelas 3.10 e 3.13 quando 

a. Cada nó conhece apenas as distâncias até seus vizinhos imediatos. 

b. Cada nó enviou a informação que tinha na etapa anterior aos seus vizinhos imediatos. 

c. Aetapa (b) acontece pela segunda vez. 

Para a rede dada na Figura 3.53, mostre como o algoritmo de estado do enlace monta a tabela de 

roteamento para o nó D. 

Use o utilitário traceroute do Unix (tracert no Windows) para determinar a quantos saltos 

seu host está de outros hosts na Internet (por exemplo, cs.princeton.edu ou www.cisco.com). 

Quantos roteadores você atravessa apenas para sair do seu host local? Leia a página obtida pelo 

comando man para o traceroute, ou outra documentação relativa ao mesmo, e explique como 

ele é implementado. 

O que acontecerá se traceroute for usado para encontrar o caminho até um endereço não atribuído? 

Existe alguma diferença se a parte de rede ou se apenas a parte do host não estiver atribuída? 

Considere a rede mostrada na Figura 3.55. R1 e R2 são roteadores; R2 conecta-se ao mundo 

exterior. As LANs individuais são Ethernets. RB é um roteador-bridge; ele direciona o tráfego 

endereçado a ele e atua como uma bridge para outros tipos de tráfego. São usadas sub-redes 

dentro dessa rede; o ARP é usado em cada sub-rede. Infelizmente, o host A foi mal configurado e 

não usa sub-redes. Quais hosts, dentre B, C e D, podem ser alcançados por A? 

Suponha que temos as tabelas de encaminhamento mostradas na Tabela 3.16 para os nós A e E 

em uma rede onde todos os enlaces têm custo 1. Mostre um diagrama da menor rede possível 

que seja consistente com essas tabelas. 


O 


OOO 


FIGURA 3.53 Rede para os Exercícios 46, 48 e 54. 


FIGURA 3.54 Rede para o Exercício 47. 





(c) RB Resto da internet —0) 


FIGURA 3.55 Rede para o Exercício 51. 
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Tabela 3.16 Tabelas de encaminhamento para o Exercício 52 











A 

Nó Custo PróximosSalto 
B 1 B 

C B 

D 1 D 

E 2 B 

F 3 D 

Nó Custo PróximoSalto 
A 3 E 

B 2 C 

C 1 C 

D 2 E 

E 1 E 


Tabela 3.17 Tabelas de encaminhamento para o Exercício 53 











A 

Nó Custo PróximoSalto 
B 1 B 

E 1 C 

D 2 B 

E 3 C 

F 2 Ç 

F 

Nó Custo PróximoSalto 
A 2 C 

B 3 C 

C 1 E 

D 2 a 

E 1 E 


“| 53. Suponha que tenhamos as tabelas de encaminhamento mostradas na Tabela 3.17 para os nós A 
e E em uma rede onde todos os enlaces têm custo 1. Mostre um diagrama da menor rede possível 
que seja consistente com essas tabelas. 

54. Para a rede da Figura 3.53, suponha que as tabelas de encaminhamento sejam todas 
estabelecidas como no Exercício 46 e que depois disso os enlaces C-E falhem. Mostre: 

a. As tabelas de A, B, D e F depois que C e E tiverem reportado esta mudança. 
b. As tabelas de A e D depois de sua próxima troca mútua de informações. 
c. A tabela de C depois que A trocar informações com ele. 

55. Suponha que um roteador tenha montado a tabela de roteamento mostrada na Tabela 3.18. O 
roteador pode entregar pacotes diretamente pelas interfaces 0 e 1, ou então pode encaminhar 
pacotes aos roteadores R2, R3 ou R4. Descreva o que o roteador faz com um pacote endereçado a 
cada um dos seguintes destinos: 

128.96.39.10 

128.96.40.12 

128.96.40.151 

192.4.153.17 

192.4.153.90 
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Tabela 3.18 Tabela de roteamento para o Exercício 55 





NúmeroSubRede MáscaraSubRede PróximoSalto 
128.96.39.0 255.255.255.128 Interface O 
128.96.39.128 255.255.255.128 Interface 1 
128.96.40.0 255.255.255.128 R2 
192.4.153.0 255.255.255.192 R3 

(padrão) R4 


Tabela 3.19 Tabela de roteamento para o Exercício 56 





NúmeroSubRede MáscaraSubRede PróximoSalto 
128.96.170.0 255.255.254.0 Interface O 
128.96.168.0 255.255.254.0 Interface 1 
128.96.166.0 255.255.254.0 R2 
128.96.164.0 255.255.252.0 R3 
(padrão) R4 
* 56. Suponha que um roteador tenha montado a tabela de roteamento mostrada na Tabela 3.19. O 


fr 57. 


58. 


59. 


© 


roteador pode entregar pacotes diretamente pelas interfaces 0 e 1, ou então pode encaminhar 

pacotes aos roteadores R2, R3 ou R4. Suponha que o roteador faça a correspondência do prefixo 

mais longo. Descreva o que o roteador faz com um pacote endereçado para cada um dos 

seguintes destinos: 

128.96.171.92 

128.96.167.151 

128.96.163.151 

128.96.169.192 

128.96.165.121 

Considere a rede simples da Figura 3.56, em que A e B trocam informações de roteamento 

por vetor de distâncias. Todos os enlaces possuem custo 1. Suponha que o enlace A-E falhe. 

a. Mostre uma sequência de atualizações da tabela de roteamento que leve a um ciclo de 
roteamento entre A e B. 

b. Estime a probabilidade de ocorrência do cenário descrito em (a), considerando que A e B 
enviam atualizações de roteamento em instantes aleatórios, cada um na mesma taxa média. 

c. Estime a probabilidade de um ciclo se formar se A transmitir via broadcast um relatório 
atualizado 1 segundo após a descoberta da falha A-E, e B transmitir informações via 
broadcast uniformemente a cada 60 segundos. 

Considere a situação envolvendo a criação de um ciclo de roteamento na rede da Figura 3.29, 

quando o enlace A-E falha. Liste todas as sequências de atualizações de tabela entre A, B e C 

referentes ao destino E, que levaram ao ciclo. Suponha que as atualizações de tabela sejam feitas 

uma por vez, que a técnica de horizonte dividido é seguida por todos os participantes e que A 

envia seu relatório inicial sobre a impossibilidade de alcançar E para B antes de C. Você pode 

ignorar as atualizações que não resultem em mudanças. 

Suponha que um conjunto de roteadores utilize todos a técnica de horizonte dividido; 

consideramos aqui sob quais circunstâncias faz diferença se eles usarem o envenenamento 

reverso além disso. 

a. Mostre que o envenenamento reverso não faz diferença na evolução do ciclo de roteamento nos 
dois exemplos descritos na Seção 3.3.2, dado que o hosts envolvidos usam horizonte dividido. 


pangp 





(A) FIGURA 3.56 Rede simples para o Exercício 57. 
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b. Suponha que os roteadores com horizonte dividido A e B de alguma forma alcancem um 
estado em que encaminham o tráfego destinado a determinado host X um para o outro. 
Descreva como essa situação evoluirá com e sem o uso do envenenamento reverso. 

c. Indique uma sequência de eventos que leve A e B a um estado de ciclo de roteamento, 
como em (b), mesmo que o envenenamento reverso seja usado. (Dica: suponha que B e A 
se conectem por meio de um enlace muito lento. Cada um deles alcança X através de um 
terceiro nó, C, e simultaneamente anunciam suas rotas um para o outro.) 

Hold Down (ou espera) é outra técnica de prevenção de ciclos no roteamento por vetor de 

distâncias, na qual os hosts ignoram as atualizações por um período de tempo até que a notícia 

de falha do enlace tenha tido uma chance de se propagar. Considere as redes da Figura 3.57, na 
qual todos os enlaces têm custo 1, exceto E-D, que tem custo 10. Suponha que o enlace E-A falhe 

e que B informe a A sua rota para F, criando um ciclo, imediatamente depois disso (essa é a rota 

falsa, via A). Especifique os detalhes de uma interpretação do mecanismo de espera e use isso 

para descrever a evolução do ciclo de roteamento nas duas redes. Até que ponto a espera pode 
prevenir a formação do ciclo na rede EAB sem adiar a descoberta da rota alternativa na rede 

EABD? 

Considere a rede da Figura 3.58, usando roteamento por estado do enlace. Suponha que o enlace 

B-F falhe e depois ocorra o seguinte em sequência: 

a. O nó H é adicionado do lado direito da rede, com uma conexão para G. 

b. O nó D é adicionado do lado esquerdo da rede, com uma conexão para C. 

c. Um novo enlace, D-A, é adicionado. 

O enlace defeituoso B-F é então restaurado. Descreva quais pacotes de estado do enlace serão 

inundados de um lado para outro. Suponha que o número de sequência inicial em todos os nós 

é 1, que nenhum pacote expire seu tempo limite e que as duas extremidades de um enlace usem 

o mesmo número de sequência em seu LSP para esse enlace, maior que qualquer número de 

sequência usado anteriormente. 

Indique as etapas, como na Tabela 3.14, do algoritmo de busca direta à medida que ele monta o 

banco de dados de roteamento para o nó A na rede mostrada na Figura 3.59. 

Indique as etapas, como na Tabela 3.14, do algoritmo de busca direta à medida que ele monta o 

banco de dados de roteamento para o nó A na rede mostrada na Figura 3.60. 

Suponha que os nós na rede mostrada na Figura 3.61 participem no roteamento por estado do 

enlace e C receba LSPs contraditórios: um deles chega de A afirmando que o enlace A-B está 

inativo, mas um outro chega de B afirmando que o enlace A-B está ativo. 

a. Como isso poderia acontecer? 

b. O que C deverá fazer? O que C pode esperar? 

Não considere que os LSPs contenham qualquer carimbo de tempo sincronizado. 
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FIGURA 3.57 Redes para o Exercício 60. FIGURA 3.58 Rede para o Exercício 61. 
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FIGURA 3.59 Rede FIGURA 3.60 Rede FIGURA 3.61 Rede 
para o Exercício 62. para o Exercício 63. para o Exercício 64. 
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65. 


66. 


67. 


68. 


69. 


70. 


71. 


72. 


Suponha que os roteadores IP descubram a respeito das redes e sub-redes IP da forma como as 

bridges com aprendizado Ethernet descobrem sobre os hosts: observando o aparecimento de 

novos hosts e a interface pela qual suas mensagens chegam. Compare isso com as técnicas de 

aprendizado existentes aplicadas por roteadores que usam algoritmos de vetor de distâncias 

a. Para uma rede de borda com uma única conexão com a Internet. 

b. Para uso interno em uma organização que não se conectou à Internet. 

Suponha que os roteadores só recebam notificações de novas redes a partir de outros roteadores 

e que os roteadores de origem recebam sua informação de rede IP através de configuração. 

Os hosts IP que não são designados como roteadores precisam descartar pacotes endereçados 

incorretamente para eles, mesmo que pudessem de alguma forma encaminhá-los corretamente. 

Na ausência desse requisito, o que aconteceria se um pacote endereçado para o endereço 

IP A fosse inadvertidamente transmitido por broadcast na camada de enlace? Que outras 

justificativas para esse requisito você pode imaginar? 

Leia a página obtida pelo comando man para o utilitário netstat do Unix/Windows, ou outra 

documentação para o mesmo,. Use o netstat para exibir a tabela de roteamento atual no seu 

host. Explique a finalidade de cada entrada. Qual é, na prática, o número mínimo de entradas? 

Uma organização recebeu o prefixo 212.1.1/24 (classe C) e deseja formar sub-redes para quatro 

departamentos, com os hosts distribuídos da seguinte forma: 

A 75 hosts 

B 35hosts 

C 20hosts 

D 18 hosts 

Existem 148 hosts no total. 

a. Mostre um arranjo possível de máscaras de sub-rede para que isso seja possível. 

b. Sugira o que a organização poderia fazer se o departamento D crescesse para 32 hosts. 

Suponha que os hosts A e B estejam em uma LAN Ethernet com endereço de rede IP 200.0.0/24. 

Pretende-se conectar um host C à rede por meio de uma conexão direta com B (ver Figura 3.62). 

Explique como fazer isso usando sub-redes; mostre atribuições de sub-rede de exemplo. 

Suponha que um prefixo de rede adicional não esteja disponível. Qual a consequência disso para 

o tamanho da LAN Ethernet? 

Um método alternativo para conectar o host C do Exercício 69 é usar um proxy ARP e 

roteamento: B concorda em rotear o tráfego de e para C e também responde a consultas ARP 

para C recebidas pela Ethernet. 

a. Indique todos os pacotes enviados, com endereços físicos, enquanto A usa ARP para localizar 
e depois enviar um pacote para C. 

b. Mostre a tabela de roteamento de B. Que peculiaridade ela precisa ter? 

Suponha que duas sub-redes compartilhem a mesma LAN física; os hosts em cada sub-rede 

verão os pacotes de broadcast da outra sub-rede. 

a. Como o DHCP se sairá se dois servidores, um para cada sub-rede, coexistirem na LAN 
compartilhada? Que problemas poderiam [e podem!) surgir? 

b. O ARP será afetado por esse compartilhamento? 

A Tabela 3.20 é uma tabela de roteamento usando CIDR. Os bytes de endereço estão em 

hexadecimal. A notação “/12” em C4.50.0.0/12 indica uma máscara de rede com 12 bits 1 iniciais: 

FEF0.0.0. Observe que as três últimas entradas abrangem cada endereço e, portanto, podem 


(e) 
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| | FIGURA 3.62 Rede para o Exercício 69. 
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Tabela 3.20 Tabela de roteamento para o Exercício 72 





Rede/ComprimentoMáscara PróximoSalto 
C4.50.0.0/12 A 
C4.5E.10.0/20 B 
C4.60.0.0/12 Ç 
C4.68.0.0/14 D 
80.0.0.0/1 E 
40.0.0.0/2 F 
00.0.0.0/2 G 


Tabela 3.21 Tabela de roteamento para o Exercício 73 





Rede/ComprimentoMáscara PróximoSalto 
C4.5E.2.0/23 A 
C4.5E.4.0/22 B 
C4.5E.C0.0/19 € 
C4.5E.40.0/18 D 
C4.4C.0.0/14 E 
C0.0.0.0/2 F 
80.0.0.0/1 G 


73. 


74. 


ser usadas no lugar de uma rota padrão. Indique para qual próximo salto os pacotes com os 

seguintes endereços serão entregues: 

C4.5E.13.87 

C4.5E.22.09 

C3.41.80.02 

5E.43.91.12 

C4.6D.31.2E 

C4.6B.31.2E 

A Tabela 3.21 é uma tabela de roteamento usando CIDR. Os bytes de endereço estão em 

hexadecimal. A notação “/12” em C4.50.0.0/12 indica uma máscara de rede com 12 bits 1 

iniciais: FEFO.0.0. Indique para qual próximo salto os pacotes com os seguintes endereços serão 

entregues 

C4.4B.31.2E 

C4.5E.05.09 

C4.4D.31.2E 

C4.5E.03.87 

C4.5E.7E12 

. CA4.5E.D1.02 

Um ISP que tem autoridade para atribuir endereços de um prefixo /16 (um antigo endereço 

de classe B) está trabalhando com uma nova empresa para alocar uma parte do espaço de 

endereços com base no CIDR. A nova empresa precisa de endereços IP para máquinas em três 

divisões de sua rede corporativa: Engenharia, Marketing e Vendas. Essas divisões planejam 

crescer da seguinte forma: Engenharia tem 5 máquinas no início do ano 1 e pretende incluir 

1 máquina a cada semana, Marketing nunca precisará de mais do que 16 máquinas e Vendas 

precisa de 1 máquina para cada 2 clientes. No início do ano 1, a empresa não tem clientes, mas 

o modelo de vendas indica que, no início do ano 2, a empresa terá 6 clientes e cada semana 

depois disso receberá um novo cliente com probabilidade de 60%, perderá um cliente com 

probabilidade de 20% ou manterá o mesmo número com probabilidade de 20%. 

a. Que faixa de endereço seria necessária para dar suporte aos planos de crescimento da 
empresa para pelo menos 7 anos se o Marketing usar todos os seus 16 endereços e os planos 
de Vendas e Engenharia se comportarem conforme o esperado? 


»»enco 
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b. Quanto tempo essa atribuição de endereços durará? Quando a empresa estiver sem espaço 
para novos endereços, como os endereços estariam atribuídos aos três grupos? 

c. Se, em vez de usar o endereçamento CIDR, fosse necessário usar os endereços com classes 
no estilo antigo, que opções a nova empresa teria em termos de obtenção do espaço de 
endereços? 

75. Proponha um algoritmo de busca para uma tabela de encaminhamento contendo prefixos de 
tamanhos variáveis, que não exija uma busca linear da tabela inteira para localizar a entrada 
de correspondência mais longa. 


Interligação avançada de redes 


Cada aparente igualdade esconde uma hierarquia. 
Mason Cooley 


E E Problema: escalabilidade até bilhões E 


Até aqui, vimos como montar uma inter-rede que consiste em uma série de redes de tipos 
diferentes. Ou seja, lidamos com o problema da heterogeneidade. O segundo problema crítico 

na interligação de redes — provavelmente o problema fundamental para todas as redes — é a 
escala. Para entender o problema da escala, é preciso considerar o crescimento da Internet, que 
praticamente dobrou de tamanho a cada ano durante 30 anos. Esse tipo de crescimento nos força 
a encarar uma série de desafios. 

O principal deles é: como você constrói um sistema de roteamento capaz de tratar de centenas 
de milhares de redes e bilhões de nós finais? Conforme veremos neste capítulo, a maior parte das 
abordagens para enfrentar a escalabilidade do roteamento depende da introdução de hierarquia. 
Podemos introduzir a hierarquia na forma de áreas dentro de um domínio; também usamos a 
hierarquia para obter escalabilidade no sistema de roteamento entre os domínios. O protocolo 
de roteamento entre domínios que permitiu que a Internet se expandisse para o seu tamanho 
atual é o BGP Vamos examinar como o BGP opera e considerar os desafios enfrentados pelo BGP à 
medida que a Internet continua a crescer. 

Bastante relacionado com a escalabilidade do roteamento é o problema do endereçamento. 
Mesmo há duas décadas, tornou-se evidente que o esquema de endereçamento de 32 bits do IP 
versão 4 não duraria para sempre. Isso levou à definição de uma nova versão do IP — a versão 6, 
pois a versão 5 tinha sido usada em um experimento anterior. O IPv6 principalmente expande o 
espaço de endereços, mas também acrescenta diversos recursos novos, alguns deles aperfeiçoados 
do IPv4. 

Embora a Internet continue a crescer em tamanho, ela também precisa evoluir em termos de 
funcionalidade. As últimas seções deste capítulo abordam algumas melhorias significativas 

nas funcionalidades da Internet. A primeira, o multicast, é uma melhoria do modelo de serviço 
básico. Mostramos como o multicast — a capacidade de entregar os mesmos pacotes a um grupo 
de receptores de forma eficaz — pode ser incorporado a uma inter-rede, e descrevemos vários dos 
protocolos de roteamento que foram desenvolvidos para dar suporte ao multicast. A segunda 
melhoria, a comutação de rótulos multiprotocolo (MPLS — Multiprotocol Label Switching), 
modifica o mecanismo de encaminhamento das redes IP Essa modificação permitiu algumas 
mudanças no modo como o roteamento IP é realizado e nos serviços oferecidos pelas redes 

IP Por fim, examinamos os efeitos da mobilidade sobre o roteamento e descrevemos algumas 
melhorias no IP para dar suporte a hosts e roteadores móveis. Para cada uma dessas melhorias, 
as questões de escalabilidade continuam a ser importantes. 


4.1 A Internet global 


Neste ponto, já vimos como conectar uma coleção heterogênea de redes para criar uma inter-rede e como 
usar a hierarquia simples do endereço IP para tornar o roteamento em uma inter-rede, até certo ponto, 
escalável. Dizemos “até certo ponto” escalável porque, embora cada roteador não precise conhecer 
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FIGURA 4.1 A estrutura em árvore da Internet em 1990. 










MidNet 
ses regional 





BARRNET 
regional 
Berkeley 


todos os hosts conectados à inter-rede, ele precisa, no modelo descrito até aqui, conhecer todas as redes 
conectadas à inter-rede. A Internet de hoje possui centenas de milhares de redes conectadas a ela (ou 
mais, dependendo de como você conta). Os protocolos de roteamento como aqueles que discutimos 
não escalam para esses tipos de números. Esta seção examina uma série de técnicas que melhoram 
bastante a escalabilidade e que permitiram que a Internet crescesse tanto assim. 

Antes de abordarmos essas técnicas, precisamos ter uma ideia geral em nossas cabeças sobre qual 
a aparência da Internet global. Ela não é apenas uma interconexão aleatória de Ethernets, mas assume 
uma forma que reflete o fato de que ela interconecta muitas organizações diferentes. A Figura 4.1 
mostra uma representação simples do estado da Internet em 1990. Desde essa época, a topologia 
da Internet se tornou muito mais complexa do que essa figura sugere — apresentamos uma imagem 
ligeiramente mais precisa da Internet atual na Seção 4.1.2 e na Figura 4.4 —, mas esta figura servirá 
por enquanto. 

Uma das características que se sobressaem nessa topologia é que ela consiste em locais de usuários 
finais (por exemplo, Stanford University) que se conectam a redes de provedores de serviços (por exemplo, 
BARRNET era uma rede de provedor que atendia a locais na área da Baía de São Francisco). Em 1990, muitos 
provedores atendiam a uma região geográfica limitada e, portanto, eram conhecidos como redes regionais. 
As redes regionais, por sua vez, eram conectadas por um backbone nacional. Em 1990, esse backbone era 
patrocinado pela National Science Foundation (NSF) e, portanto, era chamado de backbone NSFNET. Embora 
o detalhe não seja mostrado nessa figura, as redes de provedores normalmente são montadas a partir de um 
grande número de enlaces ponto a ponto (por exemplo, enlaces T1 e DS3 no passado, enlaces SONET OC-48 
e OC-192 hoje) que se conectam a roteadores; de modo semelhante, cada local de usuário final normalmente 
não é uma única rede, mas consiste em várias redes físicas conectadas por roteadores e bridges. 

Observe, na Figura 4.1, que cada provedor e usuário final provavelmente será uma entidade adminis- 
trativamente independente. Isso tem algumas consequências significativas no roteamento. Por exemplo, 
é bem provável que diferentes provedores terão diferentes ideias sobre o melhor protocolo de roteamento 
a usar dentro de suas redes e sobre como as métricas deverão ser atribuídas aos enlaces em sua rede. 
Devido a essa independência, a rede de cada provedor normalmente é um único sistema autônomo (AS — 
Autonomous System). Definiremos esse termo mais precisamente na Seção 4.1.2, mas, por enquanto, é 
adequado pensar em um AS como uma rede que é administrada independentemente de outros ASs. 

O fato de que a Internet tem uma estrutura discernível pode ser usado para o nosso proveito enquanto 
enfrentamos o problema da escalabilidade. De fato, precisamos lidar com duas questões de escala 
relacionadas. A primeira é a escalabilidade do roteamento. Precisamos encontrar maneiras de minimizar 
a quantidade de números de rede que são transportados nos protocolos de roteamento e armazenados 
nas tabelas de roteamento dos roteadores. A segunda é a utilização de endereços — ou seja, garantir que 
o espaço de endereços IP não seja consumido muito rapidamente. 

No decorrer deste livro, vemos o princípio da hierarquia sendo usado várias vezes para melhorar a 
escalabilidade. Vimos, no capítulo anterior, como a estrutura hierárquica dos endereços IP especialmen- 
te com a flexibilidade fornecida pelo Classless Interdomain Routing (CIDR) e sub-redes, pode melhorar 
a escalabilidade do roteamento. Nas próximas duas seções, veremos outros usos da hierarquia (e sua 
parceira, a agregação) para oferecer maior escalabilidade, primeiro em um único domínio e depois entre 
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domínios. Nossa subseção final examina os padrões emergentes para o IP versão 6, cuja invenção em 
grande parte foi o resultado de preocupações com a escalabilidade. 


4.1.1 Áreas de roteamento 


Como um primeiro exemplo do uso da hierarquia para expandir o sistema de roteamento, vamos exa- 
minar como os protocolos de roteamento por estado do enlace (como OSPF e IS-IS) podem ser usados 
para dividir um domínio de roteamento em subdomínios chamados de áreas. (A terminologia varia um 
pouco entre os protocolos — usamos aqui a terminologia do OSPE) Acrescentando esse nível extra de 
hierarquia, permitimos que domínios isolados cresçam sem sobrecarregar os protocolos de roteamento 
ou lançar mão de protocolos de roteamento interdomínio mais complexos, descritos a seguir. 

Uma área é um conjunto de roteadores que são configurados administrativamente para trocar 
informações de estado do enlace uns com os outros. Existe uma área especial — a área de backbone, 
também conhecida como área 0. Um exemplo de um domínio de roteamento dividido em áreas aparece 
na Figura 4.2. Os roteadores R1, R2 e R3 são membros da área de backbone. Eles também são membros 
de pelo menos uma área que não seja de backbone; R1 é, na realidade, um membro da área 1 e da área 2. 
Um roteador que é membro da área de backbone e de uma área que não é de backbone é um roteador 
de borda da área (ABR — Area Border Router). Observe que estes são distintos dos roteadores que estão na 
borda de um AS, que são denominados roteadores de borda do AS para facilitar a distinção entre eles. 

O roteamento dentro de uma única área se dá exatamente conforme descrito na Seção 3.3.3. Todos 
os roteadores na área enviam anúncios de estado do enlace uns aos outros e, assim, montam um mapa 
completo e consistente da área. Porém, os anúncios de estado do enlace dos roteadores que não são 
roteadores de borda da área não saem da área em que foram originados. O efeito disso é que os processos 
de inundação e cálculo de rota tornam-se consideravelmente mais escaláveis. Por exemplo, o roteador R4 
na área 3 nunca verá um anúncio de estado do enlace do roteador R8 na área 1. Como consequência, ele 
não obterá qualquer informação sobre a topologia detalhada das áreas que não sejam a sua própria. 

Como, então, um roteador em uma área determina o próximo salto correto para um pacote destinado 
a uma rede em outra área? A resposta para isso torna-se clara se imaginarmos o caminho de um pacote 
que precisa viajar de uma área que não seja de backbone para outra como se fosse dividido em três partes. 
Primeiro, ele trafega de sua rede de origem até a área de backbone, depois atravessa o backbone e trafega 
do backbone à rede de destino. Para que isso funcione, os roteadores de borda da área resumem as in- 
formações de roteamento que eles descobriram de uma área e as tornam disponível em seus anúncios 
para outras áreas. Por exemplo, R1 recebe anúncios de estado do enlace de todos os roteadores na área 
1e, assim, pode determinar o custo de alcançar qualquer rede na área 1. Quando R1 envia anúncios de 
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FIGURA 4.2 Um domínio dividido em áreas. 
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estado do enlace para a área 0, ele anuncia os custos de alcançar as redes na área 1, como se todas essas 
redes estivessem conectadas diretamente a R1. Isso permite que todos os roteadores da área 0 descu- 
bram o custo para alcançar todas as redes na área 1. Os roteadores de borda da área, então, resumem 
essa informação e a anunciam às áreas que não são de backbone. Assim, todos os roteadores descobrem 
como alcançar todas as redes no domínio. 

Observe que, no caso da área 2, existem dois ABRs e que os roteadores na área 2, portanto, terão 
de fazer uma escolha sobre qual será usado para alcançar o backbone. Isso é muito fácil, pois tanto R1 
como R2 estarão anunciando custos para várias redes, de modo que ficará claro qual é a melhor esco- 
lha quando os roteadores na área 2 executarem seu algoritmo do caminho mais curto. Por exemplo, é 
bastante claro que R1 será uma escolha melhor do que R2 para os destinos na área 1. 

Ao dividir um domínio em áreas, o administrador da rede tenta encontrar um equilíbrio entre es- 
calabilidade e otimização do roteamento. O uso de áreas força todos os pacotes trafegando de uma 
área para outra a seguirem pela área de backbone, mesmo que um caminho mais curto possa estar 
disponível. Por exemplo, mesmo se R4 e R5 fossem conectados diretamente, os pacotes não trafegariam 
diretamente entre eles, porque eles estão em áreas diferentes e que não são de backbone. Acontece que 
a necessidade de escalabilidade, frequentemente, é mais importante do que a necessidade de usar o 
caminho absolutamente mais curto. 


Isso ilustra um princípio importante no projeto de redes. Frequentemente, existe uma escolha a ser feita em 
busca de um equilíbrio entre algum tipo de otimização e escalabilidade. Quando a hierarquia é introduzida, 
a informação é escondida de alguns nós na rede, prejudicando sua capacidade de tomar decisões 


perfeitamente ótimas. Porém, a ocultação de informações é essencial à escalabilidade, pois evita que todos 
os nós tenham conhecimento global. É invariavelmente verdadeiro em grandes redes que a escalabilidade é 
um objetivo de projeto mais premente do que a otimização perfeita. 





Por fim, observamos que existe um truque pelo qual os administradores de rede podem decidir 
de forma mais flexível quais roteadores ficam na área 0. Esse truque usa a ideia de um enlace virtual 
entre os roteadores. Esse enlace virtual é obtido configurando um roteador que não esteja conectado 
diretamente à área 0, de forma que ele troque informações de roteamento de backbone com um roteador 
que esteja em tal área. Por exemplo, um enlace virtual poderia ser configurado de R8 para R1, fazendo 
assim com que R8 se tornasse parte do backbone. R8 agora participaria no processo de inundação de 
anúncios do estado do enlace com os outros roteadores na área 0. O custo do enlace virtual de R8 para 
R1 é determinado pela troca de informações de roteamento que ocorre na área 1. Essa técnica pode 
ajudar a otimizar o roteamento. 

& 


4.1.2 Roteamento interdomínios (BGP) ao: 


BGP 
No início deste capítulo, apresentamos a noção de que a Internet é organizada como sistemas autôno- 


mos, cada um sob o controle de uma única entidade administrativa. A rede interna complexa de uma 
corporação poderia ser um único AS, assim como o poderia a rede de um único provedor de serviços 
de Internet (ISP). A Figura 4.3 mostra uma rede simples, com dois sistemas autônomos. 

A ideia básica por trás dos sistemas autônomos é fornecer um modo adicional de agregar hierarqui- 
camente as informações de roteamento em uma grande inter-rede, melhorando assim a escalabilidade. 
Agora, dividimos o problema de roteamento em duas partes: rotear dentro de um único sistema autôno- 
mo e rotear entre sistemas autônomos. Como outro nome usado para sistemas autônomos na Internet é 
domínios de roteamento, vamos nos referir às duas partes do problema de roteamento como roteamento 
interdomínios e roteamento intradomínio. Além de melhorar a escalabilidade, o modelo de AS desacopla 
o roteamento intradomínio que ocorre em um AS daquele que ocorre em outro. Assim, cada AS pode 
executar quaisquer protocolos de roteamento intradomínio que escolher. Ele pode ainda usar rotas 
estáticas ou múltiplos protocolos, se for desejado. O problema de roteamento interdomínios consiste, 
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FIGURA 4.3 Uma rede com dois sistemas autônomos. 
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então, em ter diferentes ASs compartilhando informações sobre alcance — descrições do conjunto de 
endereços IP que podem ser alcançados por meio de determinado AS — uns com os outros. 








Desafios no roteamento interdomínios 

Talvez o desafio mais importante do roteamento interdomínios atualmente seja a necessidade de 
que cada AS determine suas próprias políticas de roteamento. Um exemplo simples de política de 
roteamento em um AS em particular pode se parecer com isto: “Sempre que possível, prefiro enviar 
tráfego pelo AS X em vez do ASY, mas usarei o AS Y se ele for o único caminho, e nunca desejo trans- 
portar tráfego do AS X para o ASY ou vice-versa”. Essa política seria típica quando eu estiver pagando 
algum dinheiro aos ASs X e Y para conectar meu AS ao restante da Internet, e o AS X for meu provedor 
preferível de conectividade, com o AS Y sendo a alternativa. Como eu vejo tanto o AS X quanto o ASY 
como provedores (e presume-se que eu lhes pague para desempenhar esse papel), não espero ajudá-los 
transportando tráfego entre eles por meio da minha rede (isso é chamado de tráfego de trânsito). 
Quanto maior for o número de sistemas autônomos aos quais eu estiver conectado, mais complexas as 
políticas que eu poderei ter, especialmente quando se considera provedores de backbone, que podem 
se interconectar com dezenas de outros provedores e centenas de clientes, com diferentes acordos 
econômicos (os quais afetam as políticas de roteamento) com cada um. 

Um objetivo de projeto importante do roteamento interdomínios é que políticas como a do exemplo 
anterior, e outras muito mais complexas, devem ser aceitas pelo sistema de roteamento interdomínios. 
Para tornar o problema mais difícil, cada sistema autônomo precisa poder implementar essa política sem 
qualquer ajuda de outros sistemas autônomos, e de forma a resistir a possíveis erros de configuração ou 
comportamento malicioso de outros sistemas autônomos. Além disso, normalmente há um desejo de 
manter as políticas privadas, pois as entidades que executam os sistemas autônomos - principalmente 
ISPs — normalmente estão competindo entre si e não querem que seus acordos econômicos se tornem 
públicos. 

Existiram dois principais protocolos de roteamento interdomínios na história da Internet. O primeiro 
foi o Exterior Gateway Protocol (EGP), que teve uma série de limitações, talvez a mais grave sendo que ele 
restringia a topologia da Internet de modo bastante significativo. O EGP foi projetado quando a Internet 
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FIGURA 4.4 Uma Internet simples com múltiplos provedores. 


tinha uma topologia do tipo árvore, conforme ilustramos na Figura 4.1, e não permitia que a topologia 
se tornasse mais geral. Observe que, nessa estrutura tipo árvore simples, existe um único backbone, e 
os sistemas autônomos são conectados somente como pais e filhos, e não como pares. 

O substituto do EGP é o Border Gateway Protocol (BGP), que estava em sua quarta versão no momento 
em que este livro foi escrito (BGP-4). O BGP normalmente é considerado como uma das partes mais 
complexas da Internet. Veremos aqui alguns dos seus pontos fortes. 

Diferente de seu predecessor EGP o BGP praticamente não faz qualquer suposição sobre como os 
sistemas autônomos são interconectados — eles formam um grafo arbitrário. Esse modelo é claramente 
genérico o suficiente para acomodar inter-redes não estruturadas em árvore, como a imagem sim- 
plificada de uma Internet com múltiplos provedores mostrada na Figura 4.4. (Acontece que ainda existe 
algum tipo de estrutura na Internet, como veremos em seguida, mas não é nada tão simples como uma 
árvore, e o BGP não faz qualquer suposição sobre tal estrutura.) 

Diferente da Internet simples estruturada em árvore, mostrada na Figura 4.1, ou mesmo da imagem 
bastante simples da Figura 4.4, a Internet de hoje consiste em um conjunto de redes ricamente interco- 
nectadas, operadas principalmente por empresas privadas (ISPs) em vez de governos. Muitos provedores 
de serviços de Internet (ISPs) existem principalmente para oferecer serviço aos “consumidores” (ou 
seja, indivíduos com computadores em suas casas), enquanto outros oferecem algo mais parecido com 
o antigo serviço de backbone, interconectando outros provedores e, às vezes, corporações maiores. 
Frequentemente, muitos provedores se organizam para se interconectar entre si em um único ponto 
de troca de tráfego. 

Para ter uma ideia melhor de como poderíamos gerenciar o roteamento entre essa complexa in- 
terconexão de sistemas autônomos, podemos começar definindo alguns termos. Definimos tráfego 
local como o tráfego que se origina em ou termina em nós dentro de um AS, e tráfego de trânsito como 
o tráfego que passa por um AS. Podemos classificar os sistemas autônomos em três tipos gerais: 


e AS stub — um AS que tem apenas uma única conexão com outro AS; esse AS só transportará 
tráfego local. A pequena corporação na Figura 4.4 é um exemplo de um AS stub. 

e ASmultihomed — um AS que possui conexões com mais de um AS, mas que se recusa a transportar 
tráfego de trânsito, como a grande corporação no alto da Figura 4.4. 

e AS de trânsito — um AS que tem conexões com mais de um outro AS e que é projetado para 
transportar tráfego de trânsito e local, como os provedores de backbone na Figura 4.4. 


Embora a discussão sobre roteamento na Seção 3.3 focalizasse a descoberta de caminhos ideais com 
base na minimização de algum tipo de métrica de enlace, os objetivos do roteamento interdomínios 
são um pouco mais complexos. Primeiro, é preciso encontrar algum caminho para o destino desejado 
que não tenha ciclos. Segundo, os caminhos precisam ser compatíveis com as políticas dos diversos 
sistemas autônomos ao longo do caminho — e, como já vimos, essas políticas poderiam ser quase arbi- 
trariamente complexas. Assim, enquanto o roteamento intradomínio se concentra em um problema 
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bem definido de otimização do custo escalar do caminho, o roteamento interdomínios volta-se à des- 
coberta de um caminho sem ciclos, compatível com a política - um problema de otimização muito 
mais complexo. 

Existem outros fatores que dificultam o roteamento interdomínios. O primeiro é simplesmente uma 
questão de escala. Um roteador de backbone da Internet precisa ser capaz de encaminhar qualquer 
pacote destinado a qualquer lugar na Internet. Isso significa ter uma tabela de roteamento que forneça 
uma correspondência para qualquer endereço IP válido. Embora o CIDR tenha ajudado a controlar o 
número de prefixos distintos que são transportados no roteamento de backbone da Internet, inevita- 
velmente existe muita informação de roteamento para ser passada entre roteadores — da ordem de 300 
mil prefixos no momento em que este livro foi escrito.! 

Outro desafio no roteamento interdomínio surge pela natureza autônoma dos domínios. Observe 
que cada domínio pode executar seus próprios protocolos de roteamento interior e usar qualquer 
esquema escolhido para atribuir métricas aos caminhos. Isso significa que é impossível calcular 
custos de caminho que carreguem algum significado para um caminho que cruze vários sistemas 
autônomos. Um custo de 1.000 através de um provedor poderia significar que aquele é um ótimo, 
mas poderia significar um caminho inaceitavelmente ruim do ponto de vista de outro provedor. 
Como resultado, o roteamento interdomínios anuncia apenas a facilidade de alcance. O conceito de 
facilidade de alcance é basicamente uma afirmação de que “você pode alcançar essa rede por meio 
deste AS”. Isso significa que é basicamente impossível que o roteamento interdomínios escolha um 
caminho ideal. 

A natureza autônoma do interdomínio levanta a questão da confiança. O provedor A poderia não 
estar disposto a acreditar em certos anúncios do provedor B, por medo de que o provedor B anuncie 
informações de roteamento errôneas. Por exemplo, confiar no provedor B quando ele anuncia uma 
ótima rota para qualquer lugar na Internet pode ser uma escolha desastrosa se o provedor B tiver 
cometido um erro configurando seus roteadores ou tiver capacidade insuficiente para transportar 
o tráfego. 

A questão da confiança também está relacionada com a necessidade de dar suporte a políticas 
complexas, conforme observado anteriormente. Por exemplo, eu poderia estar disposto a confiar em 
determinado provedor somente se ele anunciasse o alcance para certos prefixos, e, dessa forma, eu 
teria uma política que diria: “Use o AS X para alcançar apenas os prefixos p e q, se, e somente se, o ASX 
anunciar que é capaz de alcançar esses prefixos”. 


Fundamentos do BGP 

Cada AS tem um ou mais roteadores de borda, por meio dos quais os pacotes entram e saem do AS. Em 
nosso exemplo simples da Figura 4.3, os roteadores R2 e R4 seriam roteadores de borda. (Com o passar 
dos anos, os roteadores foram às vezes chamados de gateways, daí os nomes dos protocolos BGP e EGP) 
Um roteador de borda é simplesmente um roteador IP que está encarregado da tarefa de encaminhar 
pacotes entre sistemas autônomos. 

Cada AS que participa no BGP também precisa ter, pelo menos, um interlocutor BGP, um roteador 
capaz de “falar” BGP com outros interlocutores BGP em outros sistemas autônomos. É comum descobrir 
que os roteadores de borda também são interlocutores BGP mas isso não é obrigatório. 

O BGP não pertence a qualquer uma das duas classes principais de protocolos de roteamento 
(protocolos de vetor de distâncias e estado do enlace) descritas na Seção 3.3. Diferentemente desses 
protocolos, o BGP anuncia caminhos completos como uma lista enumerada de sistemas autônomos 
para alcançar uma rede em particular. Ele, às vezes, é chamado de protocolo de vetor de caminhos por 
esse motivo. O anúncio de caminhos completos é necessário para permitir que as decisões políticas do 
tipo descrito anteriormente sejam feitas de acordo com os desejos de um AS em particular. Ele também 
permite que os ciclos de roteamento sejam prontamente detectados. 

Para ver como isso funciona, considere a rede de exemplo muito simples da Figura 4.5. Suponha que 
os provedores sejam redes de trânsito, enquanto as redes dos clientes sejam stubs. Um interlocutor BGP 


IVerifique nas referências vivas, ao final deste capítulo, uma estimativa atual desse número. 
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FIGURA 4.5 Exemplo de uma rede executando BGP. 


para o AS do provedor A (AS 2) seria capaz de anunciar informações de capacidade de alcançar cada um 
dos números de rede atribuídos aos clientes P e Q. E assim, ele diria, portanto: “As redes 128.96, 192.4.153, 
192.4.32 e 192.4.3 podem ser alcançadas diretamente pelo AS 2”. A rede de backbone, ao receber esse 
anúncio, pode noticiar: “As redes 128.96, 192.4.153, 192.4.32 e 192.4.3 podem ser alcançadas por meio 
do caminho (AS 1, AS 2)”. De modo semelhante, ela poderia anunciar: “As redes 192.12.69, 192.4.54 e 
192.4.23 podem ser alcançadas por meio do caminho (AS 1, AS 3)”. 

Uma tarefa importante do BGP é impedir o aparecimento de caminhos cíclicos. Por exemplo, 
considere a rede ilustrada na Figura 4.6. Ela difere da Figura 4.5 somente pelo acréscimo de um enlace 
extra entre o AS 2 e o AS 3, mas o efeito agora é que o grafo de sistemas autônomos tem um ciclo nele. 
Suponha que o AS 1 descubra que pode alcançar a rede 128.96 através do AS 2, de modo que anuncia 
esse fato ao AS 3, que por sua vez o anuncia de volta ao AS 2. Na ausência de qualquer mecanismo de 
prevenção de ciclos, o AS 2 agora poderia decidir que o AS 3 é a rota preferida para os pacotes destinados 
à rede 128.96. Se o AS 2 começar a enviar pacotes endereçados a 128.96 para AS 3, o AS 3 os enviará 
para AS 1; AS 1 os enviaria de volta para AS 2; e eles ficam para sempre viajando em círculos. Previne-se 
isso transportando o caminho completo, com cada AS nas mensagens de roteamento. Nesse caso, o 
anúncio para um caminho até 128.95 recebido pelo AS 2 a partir do AS 3 teria um caminho de AS igual 
a (AS 3, AS 1, AS 2, AS 4). O AS 2 vê a si mesmo nesse caminho e, portanto, conclui que esse não é um 
caminho útil para se utilizar. 

Para que esta técnica de prevenção de ciclos funcione, os números de AS transportados no BGP 
claramente, precisam ser unívocos. Por exemplo, AS 2 só pode se reconhecer no caminho do AS do 
exemplo anterior se nenhum outro AS se identificar da mesma maneira. Números de AS eram, até pouco 
tempo, números de 16 bits, sendo atribuídos por uma autoridade central para garantir a exclusividade. 
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FIGURA 4.6 Exemplo de um ciclo entre sistemas autônomos. 
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Embora 16 bits só permitam cerca de 65.000 sistemas autônomos, o que pode não parecer muita coisa, 
observamos que um AS stub não precisa de um número de AS unívoco, e isso abrange a grande maioria 
das redes que não são de provedores de serviço.? 

Determinado AS só anunciará rotas que ele considera boas o suficiente para si mesmo. Ou seja, se um 
interlocutor BGP tiver uma escolha entre várias rotas diferentes para um destino, ele escolherá a melhor 
de acordo com suas próprias políticas locais, e depois essa será a rota que ele anunciará. Além disso, 
um interlocutor BGP não é obrigado a anunciar qualquer rota para um destino, mesmo que haja uma. É 
assim que um AS pode implementar uma política de não fornecer trânsito — recusar-se a anunciar rotas 
para prefixos que não estejam contidos dentro desse AS, mesmo que ele saiba como alcançá-los. 

Dado que os enlaces falham e as políticas mudam, os interlocutores BGP precisam ser capazes de 
cancelar caminhos anunciados anteriormente. Isso é feito com uma forma de anúncio negativo co- 
nhecido como rota removida. Informações de alcance positivas e negativas são executadas em uma 
mensagem de atualização BGP cujo formato aparece na Figura 4.7. (Observe que os campos nessa figura 
são múltiplos de 16 bits, diferentemente de outros formatos de pacote neste capítulo.) 

Diferente de outros protocolos de roteamento descritos no capítulo anterior, o BGP é definido para 
executar sobre o TCP o protocolo de transporte confiável descrito na Seção 5.2. Como os interlocutores 
BGP podem contar com a confiabilidade do TCP isso significa que qualquer informação que foi enviada 
de um interlocutor para outro não precisa ser enviada novamente. Assim, desde que nada tenha mu- 
dado, um interlocutor BGP pode simplesmente enviar uma mensagem de keepalive (manutenção da 
sessão) ocasional que diz, portanto: “Estou aqui e nada mudou”. Se esse roteador falhasse ou se fosse 
desconectado de seu par, ele deixaria de enviar os keepalives, e os outros roteadores que descobriram 
rotas a partir dele assumiriam que essas rotas não são mais válidas. 


Relacionamentos e políticas comuns de AS 

Apesar de termos afirmado que as políticas podem ser arbitrariamente complexas, acontece que 
existem algumas políticas comuns, refletindo os relacionamentos comuns entre sistemas autônomos. 
Os relacionamentos mais comuns são ilustrados na Figura 4.8. Os três relacionamentos comuns e as 
políticas que os acompanham são os seguintes: 


e Provedor-cliente — provedores têm como modelo de negócios conectar seus clientes ao restante da 
Internet. Um cliente poderia ser uma corporação, ou então um ISP menor (que pode ter clientes 
próprios). Assim, a política comum é anunciar todas as rotas que eu conheço para o meu cliente e 
anunciar as rotas que eu descubro do meu cliente para todos. 
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FIGURA 4.7 Formato dos pacotes FIGURA 4.8 Relacionamentos comuns entre AS. 
de atualização do BGP-4. 


2Números de AS de 32 bits também têm sido definidos e passaram a ser usados por volta de 2009, garantindo, assim, que o 
espaço de números de AS não se torne um recurso escasso. 
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e Cliente-provedor -no outro sentido, o cliente deseja receber tráfego direcionado a ele (e aos seus 
clientes, se os tiver) por seu provedor, e deseja poder enviar tráfego ao restante da Internet por 
meio de seu provedor. Assim, a política comum nesse caso é anunciar meus próprios prefixos e 
rotas que descobri dos meus clientes ao meu provedor, anunciar as rotas descobertas do meu 
provedor aos meus clientes, mas não anunciar as rotas descobertas de um provedor para outro. 
Essa última parte é para garantir que o cliente não se encontre na situação de transportar tráfego 
de um provedor para outro, o que não é de seu interesse se ele estiver pagando aos provedores 
para transportar tráfego para ele. 

e Par-a terceira opção é o pareamento simétrico entre sistemas autônomos. Dois provedores que 
se veem como iguais normalmente criam pontos de troca de tráfego entre eles, de modo que 
podem acessar os clientes um do outro sem ter que pagar para outro provedor. A política comum 
aqui é anunciar rotas descobertas dos meus clientes para o meu par, anunciar as rotas aprendidas 
do meu par para meus clientes, mas não anunciar rotas do meu par para qualquer provedor ou 
vice-versa. 


Uma coisa a observar sobre essa figura é o modo como ela trouxe de volta alguma estrutura à In- 
ternet aparentemente desestruturada. Na parte mais baixa da hierarquia, temos as redes stub que são 
clientes de um ou mais provedores, e à medida que subimos na hierarquia, vemos provedores que têm 
outros provedores como seus clientes. No topo, temos provedores que têm clientes e pares, mas não 
são clientes de ninguém. Esses provedores são conhecidos como provedores de nível 1. 


Vamos voltar à pergunta de fato: Como tudo isso nos ajuda a montar redes escaláveis? Primeiro, o número 
de nós participando do BGP é da ordem do número de sistemas autônomos, que é muito menor do que 

o número de redes. Segundo, encontrar uma boa rota interdomínios é apenas uma questão de encontrar 
um caminho para o roteador de borda correto, dos quais existem apenas alguns poucos por AS. Assim, 


subdividimos por igual o problema de roteamento em partes de fácil tratamento, mais uma vez usando um 
novo nível de hierarquia para aumentar a escalabilidade. A complexidade do roteamento interdomínios 
agora é da ordem do número de sistemas autônomos, e a complexidade do roteamento intradomínio é da 
ordem do número de redes em um único AS. 





Integrando o roteamento interdominios e intradomínio 

Embora a discussão anterior ilustre como um interlocutor BGP descobre informações de roteamento 
interdomínios, ainda resta a questão de como todos os outros roteadores em um domínio recebem essa 
informação. Existem várias maneiras como esse problema pode ser resolvido. 

Vamos começar com uma situação muito simples, que também é muito comum. No caso de um AS 
stub que só se conecta a outros sistemas autônomos em um único ponto, o roteador de borda é claramen- 
te a única escolha para todas as rotas que estão fora do AS. Esse roteador pode injetar uma rota padrão 
no protocolo de roteamento intradomínio. Como resultado, essa é uma declaração de que qualquer 
rede que não tenha sido anunciada explicitamente no protocolo intradomínio pode ser alcançada por 
meio do roteador de borda. Lembre-se, pela discussão sobre encaminhamento IP na Seção 3.2, que a 
entrada padrão na tabela de encaminhamento vem depois de todas as entradas mais específicas, e ela 
corresponde a qualquer coisa que não tenha correspondência com uma entrada específica. 

O próximo passo na direção de uma maior complexidade é fazer com que os roteadores de borda 
injetem rotas específicas que eles descobriram de fora do AS. Considere, por exemplo, o roteador de 
borda de um AS provedor que se conecta a um AS cliente. Esse roteador poderia descobrir que o prefixo 
de rede 192.4.54/24 está localizado dentro do AS cliente, seja através de BGP ou porque a informação 
está configurada no roteador de borda. Ele poderia injetar uma rota para esse prefixo no protocolo de 
roteamento que é executado dentro do AS provedor. Isso poderia ser um anúncio do tipo “eu tenho um 
enlace para 192.4.54/24 de custo X”. Isso faria com que outros roteadores no AS provedor descobrissem 
que esse roteador de borda é o local para enviar pacotes destinados para esse prefixo. 
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O último nível de complexidade aparece nas redes de backbone, que descobrem tantas informações 
de roteamento do BGP que se torna muito dispendioso injetá-las no protocolo intradomínio. Por exem- 
plo, se um roteador de borda quiser injetar 10.000 prefixos que ele descobriu sobre outro AS, ele terá que 
enviar pacotes de estado do enlace muito grandes para os outros roteadores nesse AS, e seus cálculos 
de caminho mais curto se tornarão muito complexos. Por esse motivo, os roteadores em uma rede de 
backbone utilizam uma variante do BGP chamada BGP interno (iBGP) para efetivamente redistribuir as 
informações descobertas pelos interlocutores BGP nas bordas do AS para todos os outros roteadores no 
AS. (A outra variante do BGP discutida anteriormente, é executada entre sistemas autônomos e é cha- 
mada BGP externo, ou eBGP). O iBGP permite que qualquer roteador no AS descubra o melhor roteador 
de borda para usar ao enviar um pacote para qualquer endereço. Ao mesmo tempo, cada roteador no AS 
mantém informações sobre como chegar a cada roteador de borda usando um protocolo intradomínio 
convencional sem informações injetadas. Combinando esses dois conjuntos de informações, cada 
roteador no AS é capaz de determinar o próximo salto apropriado para todos os prefixos. 

Para ver como tudo isso funciona, considere a rede de exemplo simples, representando um único 
AS, da Figura 4.9. Os três roteadores de borda, A, D e E, falam eBGP com outros sistemas autônomos 
e descobrem como alcançar diversos prefixos. Esses três roteadores de borda se comunicam entre 
sie com os roteadores internos B e C montando uma malha de sessões iBGP entre todos os roteadores 
no AS. Agora, vamos focalizar em como o roteador B monta sua visão completa de como encaminhar 
pacotes para qualquer prefixo. Veja a tabela no canto superior esquerdo da Figura 4.10, que mostra a 
informação que o roteador B descobre a partir de suas sessões iBGP Ele descobre que alguns prefixos 
são alcançados melhor por meio do roteador A, alguns por D e alguns por E. Ao mesmo tempo, todos 
os roteadores no AS também estão executando algum protocolo de roteamento intradomínio, como 
o Routing Information Protocol (RIP) ou o Open Shortest Path First (OSPF). (Um termo genérico para 
protocolos intradomínio é um protocolo de gateway interior, ou IGP) Por esse protocolo completamente 
separado, B descobre como alcançar outros nós dentro do domínio, como mostra a tabela no canto 
superior direito. Por exemplo, para alcançar o roteador E, B precisa enviar pacotes para o roteador C. 
Finalmente, na tabela inferior, B monta o cenário completo, combinando as informações sobre prefixos 
externos, descoberta por meio do iBGP com as informações sobre rotas interiores para os roteadores 
de borda, descoberta por meio do IGP Assim, se um prefixo como 18.0/16 for alcançável por meio do 
roteador de borda E, e o melhor caminho interior para E é através de C, então conclui-se que qualquer 


De/para outros sistemas 
autônomos 


De/para outros sistemas 
autônomos 


FIGURA 4.9 Exemplo de roteamento 
interdomínios e intradomínio. Todos os roteadores 
executam iBGP e um protocolo de roteamento 
intradomínio. Os roteadores de borda A, De E 


De/para outros sistemas também executam eBGP para outros sistemas 
autônomos autônomos. 
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FIGURA 4.10 Tabela de roteamento BGP tabela de roteamento 








Próximo salto do f T Caminho do 
Prefixo Roteador IGP e tabela combinada no roteador B. 
BGP IGP l 
| 18.0/16 E A A 
| 12.5.5/24 A C G 
| 
| 128.34/16 D D C 
128.69./16 A E C 
Tabela do BGP para o AS Tabela do IGP para o 


roteador B 


Prefixo Caminho do IGP 


18.0/16 G 
12.5.5/24 A 
128.34/16 @ | 
128.69./16 A | 


Tabela combinada para o 
roteador B 


pacote destinado para 18.0/16 deve ser encaminhado para C. Desse modo, qualquer roteador no AS 
pode montar uma tabela de roteamento completa para qualquer prefixo que seja alcançável por meio 
de algum roteador de borda do AS. 


4.1.3 IP versão 6 (IPv6) 


Em muitos aspectos, a motivação para uma nova versão do IP é simples: lidar com o esgotamento do 
espaço de endereços IP O CIDR ajudou consideravelmente a conter a taxa em que o espaço de ende- 
reços da Internet está sendo consumida e também ajudou a controlar o crescimento das informações 
da tabela de roteamento necessárias nos roteadores da Internet. Porém, chegará um ponto em que 
essas técnicas não serão mais adequadas. Em particular, é praticamente impossível alcançar 100% de 
eficiência na utilização de endereços, de modo que o espaço de endereços será esgotado bem antes do 
host de número 4 bilhões ser conectado à Internet. Mesmo que pudéssemos usar todos os 4 bilhões 
de endereços, não é muito difícil imaginar algumas formas como esse número poderia ser esgotado, 
agora que os endereços IP são atribuídos não apenas a computadores de fato, mas também a telefones 
móveis, televisores e outros aparelhos domésticos. Todas essas possibilidades revelam que um espaço 
de endereços maior do que o fornecido pelos 32 bits será eventualmente necessário. 


Perspectiva histórica 

A IETF começou a examinar o problema de expandir o espaço de endereços IP em 1991, e várias alternativas 
foram propostas. Como o endereço IP é transportado no cabeçalho de cada pacote IP aumentar o tama- 
nho do endereço exige uma mudança no cabeçalho do pacote. Isso significa uma nova versão do IP e, por 
conseguinte, uma necessidade de novo software para cada host e roteador na Internet. Isso certamente 
não é uma questão trivial — é uma grande mudança, que precisa ser pensada com muito cuidado. 

O esforço para definir uma nova versão do IP ficou conhecido como IP de Nova Geração, ou IPng. 
Com o prosseguimento do trabalho, um número de versão oficial do IP foi atribuído, de modo que o 
IPng agora é conhecido como IPv6. Observe que a versão do IP discutida até aqui neste capítulo é a 
versão 4 (IPv4). A aparente descontinuidade na numeração acontece porque o número de versão 5 foi 
usado para um protocolo experimental há alguns anos. 

A significância de mudar para uma nova versão do IP causou um efeito de bola de neve. O sentimento 
geral entre os projetistas de rede foi que, se você for fazer uma mudança dessa grandeza, também pode, ao 
mesmo tempo, consertar o máximo possível de outras coisas no IP Consequentemente, a IETF solicitou 
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documentos de qualquer um que quisesse escrever um, pedindo informações sobre os recursos que 
poderiam ser desejados em uma nova versão do IP. Além da necessidade de acomodar roteamento e 
endereçamento escaláveis, alguns dos outros itens da lista de desejos para o IPng incluíram: 


e Suporte para serviços em tempo real. 

e Suporte para segurança. 

e Autoconfiguração (ou seja, a capacidade de os hosts se configurarem automaticamente com 
informações como seu próprio endereço IP e nome de domínio). 

e Funcionalidade de roteamento melhorada, incluindo suporte para hosts móveis. 


É interessante observar que, embora muitos desses recursos estivessem ausentes do IPv4 na época 
em que o IPv6 estava sendo projetado, o suporte para todos eles entrou no IPv4 nos últimos anos, 
geralmente usando técnicas semelhantes nos dois protocolos. Pode-se argumentar que a liberdade de 
pensar no IPv6 como uma tela em branco facilitou o projeto de novas capacidades para o IP que foram 
então usadas para aperfeiçoar o IPv4. 

Além da lista de desejos, um recurso absolutamente não negociável para o IPng foi que deveria haver 
um plano de transição para passar da versão atual do IP (versão 4) para a nova versão. Com a Internet 
sendo tão grande e não tendo um controle centralizado, seria completamente impossível ter um “dia 
marcado” em que todos desligariam seus hosts e roteadores e instalariam uma nova versão do IP Assim, 
provavelmente haverá um longo período de transição em que alguns hosts e roteadores executarão 
apenas IPv4, alguns executarão IPv4 e IPv6 e alguns executarão apenas IPv6. 

A IETF apontou um comitê chamado IPng Directorate para coletar todas as ideias sobre requisitos 
do IPng e avaliar as propostas para um protocolo se tornar o IPng. Durante o tempo de vida desse 
comitê, houve diversas propostas, algumas delas mescladas com outras, e por fim uma foi escolhida 
pelo comitê para ser a base do IPng. Essa proposta se chamava Simple Internet Protocol Plus (SIPP). O 
SIPP originalmente exigia a duplicação do tamanho de endereços IP para 64 bits. Quando o Directorate 
selecionou o SIPP eles estipularam várias mudanças, uma delas foi dobrar o espaço de endereços para 
128 bits (16 bytes). Foi por volta dessa época que o número de versão 6 foi atribuído. O restante desta 
seção descreve alguns dos principais recursos do IPv6. No momento em que este livro foi escrito, a maior 
parte das principais especificações para o IPv6 são propostas e rascunhos (drafts) de padrões no IETE 


Endereçamento e roteamento 

Acima de tudo, o IPv6 oferece um espaço de endereços de 128 bits, ao contrário dos 32 bits da versão 4. 
Assim, enquanto a versão 4 pode potencialmente endereçar 4 bilhões de nós se a eficiência da atribuição de 
endereços atingir 100%, o IPv6 pode endereçar 3,4 x 10% nós, novamente considerando 100% de eficiência. 
Como vimos, porém, 100% de eficiência na atribuição de endereço não é provável. Alguma análise de 
outros esquemas de endereçamento, como aqueles das redes telefônicas da França e dos EUA, além do 
IPv4, revelaram alguns números empíricos para a eficiência da atribuição de endereços. Com base nas 
estimativas mais pessimistas de eficiência, retiradas desse estudo, prevê-se que o espaço de endereços do 
IPv6 pode fornecer mais de 1.500 endereços por metro quadrado da superfície da Terra, o que certamente 
parece ser suficiente até mesmo quando as torradeiras em Vênus tiverem endereços IP 


Alocação do espaço de endereços 

Baseado na eficácia do CIDR no IPv4, os endereços do IPv6 também são sem classes, mas o espaço de 
endereços ainda é subdividido de diversas maneiras, com base nos bits iniciais. Em vez de especificar 
diferentes classes de endereços, os bits iniciais especificam diferentes usos do endereço IPv6. A atribui- 
ção atual de prefixos é listada na Tabela 4.1. 

Esta alocação do espaço de endereços merece alguma discussão. Primeiro, a funcionalidade inteira 
das três principais classes de endereços do IPv4 (A, Be C) está contida dentro da faixa de “tudo o mais”. Os 
endereços unicast globais, conforme veremos em breve, são muito semelhantes a endereços IPv4 sem classes, 
entretanto são muito maiores. Estes são os mais interessantes nesse ponto, correspondendo a mais de 99% 
do espaço de endereços IPv6 no total disponível para essa importante forma de endereço. (No momento em 
que este livro foi escrito, os endereços unicast do IPv6 estão sendo alocados a partir do bloco que começa 
com 001, com o espaço de endereços restante — cerca de 87% — sendo reservado para uso futuro.) 
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Tabela 4.1 Atribuições de prefixos de endereço para o IPv6 





Prefixo Uso 

00... 0 (128 bits) Não especificado 

00... 1 (128 bits) Loopback 

1111 1111 Endereços multicast 
1111 1110 10 Unicast local ao enlace 
Tudo o mais Endereços unicast globais 


O espaço de endereços de multicast é (obviamente) para multicast, servindo assim ao mesmo papel dos 
endereços de classe D no IPv4. Observe que os endereços de multicast são fáceis de distinguir - começam 
com um byte com todos os bits iguais a 1. Veremos como esses endereços são usados na Seção 4.2. 

Aideia por trás dos endereços para uso no enlace local é permitir que um host construa um endereço 
que funcionará na rede à qual está conectado sem se preocupar com a exclusividade global do endereço. 
Isso pode ser útil para a autoconfiguração, conforme veremos em seguida. De modo semelhante, os 
endereços de uso local servem para permitir que endereços válidos sejam construídos em uma região da 
rede (por exemplo, uma rede corporativa privada) que não está conectada à Internet maior; novamente, 
a exclusividade global não precisa ser um problema. 

Dentro do espaço de endereços unicast globais existem alguns tipos especiais de endereços. Um 
nó pode receber um endereço IPv6 compatível com IPv4 estendendo com zeros um endereço IPv4 
de 32 bits até 128 bits. Um nó que só é capaz de entender o IPv4 pode receber um endereço IPv6 
mapeado para IPv4 inserindo no endereço IPv4 de 32 bits um prefixo de 2 bytes no qual todos os 
bits são iguais a 1 e depois estendendo o resultado com zeros até alcançar 128 bits. Esses dois tipos 
especiais de endereços possuem usos na transição de IPv4 para IPv6 (veja a nota em destaque sobre 
esse assunto). 


TRANSIÇÃO DE IPV4 PARA IPV6 


A ideia mais importante por trás da transição do IPv4 para o IPv6 é que a Internet é muito grande e 
descentralizada para ter um “dia marcado” — um dia especificado em que cada host e roteador será atualizado 
do IPv4 para o IPv6. Assim, o IPv6 precisa ser implantado de modo incremental, de tal forma que os hosts 

e os roteadores que só entendem IPv4 possam continuar a funcionar pelo máximo de tempo possível. O 

ideal é que os nós IPv4 sejam capazes de falar indefinidamente com outros nós IPv4 e com algum conjunto 
de outros nós habilitados para usar IPv6. Além disso, os hosts IPv6 devem ser capazes de falar com outros 
nós IPv6 mesmo quando alguma parte da infraestrutura entre eles tenha suporte apenas para IPv4. Dois 
mecanismos principais foram definidos para ajudar nessa transição: operação em pilha dupla e tunelamento. 

A ideia das pilhas duplas é muito simples: nós IPv6 executam tanto IPv6 como IPv4 e usam o campo de 
Versão para decidir qual pilha deverá processar um pacote que chega. Nesse caso, o endereço IPv6 poderia 
não estar relacionado ao endereço IPv4, ou então poderia ser o endereço IPv6 mapeado para IPv4, descrito 
anteriormente nesta seção. 

A técnica básica de tunelamento, em que um pacote IP é enviado como payload de outro pacote IP foi 
descrito na Seção 3.2. Para a transição do IPv6, o tunelamento é usado para enviar um pacote IPv6 através de 
uma parte da rede que só entende IPv4. Isso significa que o pacote IPv6 é encapsulado dentro de um cabeçalho 
IPv4 que tem o endereço o ponto final do túnel em seu cabeçalho, é transmitido pela parte da rede que suporta 
apenas IPv4 e finalmente desencapsulado no ponto final do túnel. Tal ponto final poderia ser um roteador 
ou um host; em ambos os casos, ele deve ser capaz de processar o pacote IPv6 após o desencapsulamento. 

Se o ponto final for um host com um endereço IPv6 mapeado para IPv4, então o tunelamento pode ser feito 
automaticamente extraindo o endereço IPv4 do endereço IPv6 e usando-o para formar o cabeçalho IPv4. Caso 
contrário, o túnel precisa ser configurado manualmente. Nesse caso, o nó encapsulado precisa conhecer o 
endereço IPv4 da outra extremidade do túnel, pois ele não pode ser extraído do cabeçalho IPv6. Do ponto de 
vista do IPv6, a outra extremidade do túnel se parece com um nó IPv6 normal, que está apenas a um salto 

de distância, embora possa haver muitos saltos de infraestrutura IPv4 entre as extremidades do túnel. 
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Notação do endereço 
Assim como no IPv4, existe uma notação especial para escrever endereços IPv6. A representação padrão 


é x:x:x:x:x:x:x:x, onde cada “x” é uma representação hexadecimal de uma porção de 16 bits do endereço. 
Um exemplo seria 


47CD:1234:4422:AC02:0022:1234:A456:0124 


Qualquer endereço IPv6 pode ser escrito usando essa notação.” Como existem alguns tipos especiais 
de endereços IPv6, existem algumas notações especiais que podem ser úteis em certas circunstâncias. 
Por exemplo, um endereço com um grande número de Os contíguos pode ser escrito de forma mais 
compacta, omitindo todos os campos 0. Assim, 


47CD:0000:0000:0000:0000:0000:A456:0124 


poderia ser escrito como 


47CD::A456:0124 


Claramente, essa forma de abreviação só pode ser usada para um conjunto de Os contíguos em um 
endereço, para evitar ambiguidade. 

Os dois tipos de endereços IPv6 que contêm um endereço IPv4 embutido têm sua própria notação 
especial, que facilita a extração do endereço IPv4. Por exemplo, o endereço IPv6 mapeado para IPv4 de 
um host cujo endereço IPv4 era 128.96.33.81 poderia ser escrito como 


::FFFF:128.96.33.81 


Ou seja, os últimos 32 bits são escritos na notação IPv4, em vez de como um par de números hexa- 
decimais separados por um sinal de dois-pontos. Observe que o duplo sinal de dois-pontos no começo 
do endereço indica os Os iniciais. 


Endereços unicast globais 

De longe, o tipo mais importante de endereçamento que o IPv6 oferece é o antigo endereçamento 
unicast. Ele precisa fazer isso de um modo que suporte a rápida taxa de acréscimo de novos hosts na 
Internet e que permita que o roteamento seja feito de modo escalável à medida que o número de redes 
físicas na Internet cresce. Assim, no coração do IPv6 está o plano de alocação de endereços unicast que 
determina como os endereços unicast serão atribuídos aos provedores de serviços, sistemas autônomos, 
redes, hosts e roteadores. 

Na realidade, o plano de alocação de endereços que é proposto para os endereços unicast do IPv6 é 
extremamente semelhante ao que está sendo implantado com o CIDR no IPv4. Para entender como ele 
funciona e como ele oferece escalabilidade, é útil definir alguns novos termos. Podemos pensar em um 
AS não de trânsito (ou seja, um AS stub ou multihomed) como um assinante, e podemos pensar em 
um AS de trânsito como um provedor. Além disso, podemos subdividir os provedores em direto e indireto. 
Os primeiros estão conectados diretamente aos assinantes. Os últimos se conectam principalmente a 
outros provedores, não estão conectados diretamente aos assinantes e geralmente são chamados de 
redes de backbone. 

Com esse conjunto de definições, podemos ver que a Internet não é apenas um conjunto de sistemas 
autônomos arbitrariamente interconectados; ela tem alguma hierarquia intrínseca. A dificuldade está 
aproveitar essa hierarquia sem inventar mecanismos que falham quando a hierarquia não é estritamente 
observada, como acontecia com o EGP Por exemplo, a distinção entre provedores diretos e indiretos fica 


“Esta notação é comumente conhecida como “notação hexadecimal com dois pontos” (N.T.) 
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menos nítida quando um assinante se conecta a um backbone ou quando um provedor direto começa 
a se conectar a muitos outros provedores. 

Assim como com o CIDR, o objetivo do plano de alocação de endereços do IPv6 é oferecer agregação 
da informações de roteamento para reduzir a carga sobre os roteadores intradomínio. Novamente, 
a ideia principal é usar um prefixo de endereços — um conjunto de bits contíguos na extremidade 
mais significativa do endereço — para agregar informações de alcance para um grande número de 
redes e até mesmo para um grande número de sistemas autônomos. O modo principal de conseguir 
isso é atribuindo um prefixo de endereços a um provedor direto e, depois, que esse provedor direto 
atribua prefixos maiores, que comecem com esse prefixo, aos seus assinantes. É exatamente isso que 
observamos na Figura 3.22. Assim, um provedor pode anunciar um único prefixo para todos os seus 
assinantes. 

Naturalmente, a desvantagem é que, se um grupo decide trocar de provedor, ele precisará obter um 
novo prefixo de endereços e renumerar todos os nós de sua rede. Isso poderia ser uma tarefa colos- 
sal, suficiente para impedir que a maioria das pessoas sequer pense em trocar de provedor. Por esse 
motivo, há uma pesquisa contínua sobre outros esquemas de endereçamento, como endereçamento 
geográfico, em que o endereço de um local é função de sua localização, em vez do provedor ao qual 
está conectado. Atualmente, porém, o endereçamento baseado em provedor é necessário para que o 
roteamento funcione de modo eficiente. 

Observe que, embora a atribuição de endereços do IPv6 seja basicamente equivalente ao modo 
como a atribuição de endereços passou a acontecer no IPv4 desde a introdução do CIDR, o IPv6 tem a 
vantagem significativa de não ter uma grande base instalada de endereços atribuídos para ajustar em 
seus planos. 

Uma pergunta é se faz sentido para uma agregação hierárquica ocorrer em outros níveis na hierarquia. 
Por exemplo, todos os provedores deverão obter seus prefixos de endereço a partir de um prefixo alocado 
ao backbone ao qual se conectam? Visto que a maioria dos provedores se conecta a vários backbones, 
isso provavelmente não faz sentido. Além disso, como o número de provedores é muito menor do que 
o número de sites, os benefícios da agregação nesse nível são muito menores. 

Um local onde a agregação pode fazer sentido é no nível nacional ou continental. Os limites 
continentais formam divisões naturais na topologia da Internet. Se todos os endereços na Europa, 
por exemplo, tivessem um prefixo em comum, então grande parte da agregação poderia ser feita, e a 
maioria dos roteadores em outros continentes só precisaria de uma entrada na tabela de roteamento 
para todas as redes com o prefixo da Europa. Os provedores na Europa selecionariam seus prefixos 
de modo que começassem com o prefixo europeu. Usando esse esquema, um endereço IPv6 pode 
se parecer com a Figura 4.11. O RegistryID poderia ser um identificador atribuído a um registro de 
endereços europeu, com IDs diferentes atribuídos a outros continentes e países. Observe que os 
prefixos seriam de diferentes tamanhos nesse cenário. Por exemplo, um provedor com poucos clientes 
poderia ter um prefixo mais longo (e assim, um menor espaço de endereços total disponível) do que 
um com muitos clientes. 

Uma situação intricada ocorreria quando um assinante estivesse conectado a mais de um 
provedor. Que prefixo o assinante deveria usar para seu conjunto de redes? Não existe uma solução 
perfeita para o problema. Por exemplo, suponha que um assinante esteja conectado a dois prove- 
dores, X e Y. Se o assinante obtiver seu prefixo de X, então Y precisa anunciar um prefixo que não 
tem relação com seus outros assinantes e que, como consequência, não pode ser agregado. Se o 
assinante numerar parte do seu AS com o prefixo de X e parte com o prefixo de Y, ele corre o risco 
de ter metade do seu site inalcançável se a conexão com um provedor falhar. Uma solução que 
funciona muito bem se X e Y tiverem muitos assinantes em comum é que eles tenham três prefixos 


3 m n o p 125-m-n-o-p 
010 RegistryID ProviderlD SubscriberlD | SubnetID | InterfacelD 


FIGURA 4.11 Um endereço unicast baseado em provedor do IPv6. 
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entre eles: um para assinantes apenas de X, um para assinantes apenas de Y e um para os locais que 
são assinantes tanto de X como de Y. 


Formato de pacote 

Apesar do fato de que o IPv6 estende o IPv4 de várias maneiras, seu formato de cabeçalho é na realidade 
simples. Essa simplicidade deve-se a um esforço centralizado para remover as funcionalidades des- 
necessárias do protocolo. A Figura 4.12 mostra o resultado. (Para uma comparação com o IPv4, consulte 
o formato de cabeçalho mostrado na Figura 3.16.) 

Assim como em muitos cabeçalhos, este começa com um campo Versão, que é fixado em 6 para o 
IPv6. O campo Versão está no mesmo local, relativo ao início do cabeçalho, do campo Versão do IPva, 
de modo que o software de processamento de cabeçalho pode decidir imediatamente qual formato de 
cabeçalho procurar. Os campos ClasseTráfego e RótuloFluxo referem-se a questões de qualidade 
de serviço, conforme discutimos na Seção 6.5. 

O campo TamPayload fornece o tamanho do pacote, excluindo o cabeçalho IPv6, medido em 
bytes. O campo PróxCab substitui inteligentemente tanto as opções do IP como o campo Protocolo do 
IPv4. Se opções forem necessárias, então elas são transportadas em um ou mais cabeçalhos especiais 
após o cabeçalho IP e isso é indicado pelo valor do campo PróxCab. Se não houver cabeçalhos especiais, 
o campo PróxCab é a chave de demux identificando o protocolo de mais alto nível sendo executado 
sobre o IP (por exemplo, TCP ou UDP); ou seja, ele tem a mesma finalidade do campo Protocolo do IPv4. 
Além disso, a fragmentação agora é tratada como um cabeçalho opcional, o que significa que os campos 
relacionados a fragmentação do IPv4 não estão incluídos no cabeçalho IPv6. O campo LimiteSalto é 
simplesmente o TTL do IPv4, renomeado para refletir o modo como ele é realmente usado. 

Por fim, a maior parte do cabeçalho é ocupada com os endereços de origem e destino, cada um 
com 16 bytes (128 bits) de extensão. Assim, o cabeçalho IPv6 sempre tem 40 bytes de comprimento. 
Considerando que os endereços IPv6 são quatro vezes maiores que os do IPv4, isso é bastante próximo 
do cabeçalho IPv4, que tem 20 bytes de comprimento na ausência de opções. 

O modo como o IPv6 trata das opções é uma grande melhoria em relação ao IPv4. No IPv4, se quaisquer 
opções estivessem presentes, cada roteador teria que analisar o campo de opções inteiro para ver se 
qualquer uma das opções era relevante. Isso porque as opções eram todas incluídas ao final do cabeçalho 
IP como uma coleção desordenada de triplas (tipo, tamanho, valor). Em comparação, o IPv6 trata as opções 
como cabeçalhos de extensão que precisam, se estiverem presentes, aparecer em uma ordem específica. Isso 





Versão | ClasseTráfego RótuloFluxo 
TamPayload PróxCab LimiteSaltos 
EndereçoOrigem 
EndereçoDestino 





| Próximo cabeçalho/dados 


| FIGURA 4.12 Cabeçalho do pacote IPv6. 
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significa que cada roteador pode determinar rapidamente se qualquer uma das opções é relevante a ele; 
na maior parte dos casos, elas não serão. Em geral, isso pode ser determinado simplesmente examinando 
o campo PróxCab. O resultado final é que o processamento de opções é muito mais eficiente no IPv6, o 
que é um fator importante no desempenho do roteador. Além disso, a nova formatação das opções como 
cabeçalhos de extensão significa que eles podem ter um tamanho qualquer, enquanto no IPv4 eles eram 
limitados a 44 bytes no máximo. A seguir, veremos como algumas das opções são usadas. 

Cada opção tem seu próprio tipo de cabeçalho de extensão. O tipo de cada cabeçalho de extensão é 
identificado pelo valor do campo PróxCab no cabeçalho que o precede, e cada cabeçalho de extensão 
contém um campo PróxCab para identificar o cabeçalho que vem em seguida. O último cabeçalho de 
extensão será seguido por um cabeçalho da camada de transporte (por exemplo, TCP) e, neste caso, o 
valor do campo PróxCab é o mesmo que o valor que o campo Protocolo teria em um cabeçalho IPva. 
Assim, o campo PróxCab tem uma dupla tarefa; ele pode identificar o tipo do cabeçalho de extensão a 
seguir ou, no último cabeçalho de extensão, serve como uma chave de demux para identificar o protocolo 
da camada superior sendo executado sobre o IPv6. 

Considere o exemplo do cabeçalho de fragmentação, mostrado na Figura 4.13. Esse cabeçalho tem uma 
funcionalidade semelhante aos campos de fragmentação no cabeçalho IPv4, descrito na Seção 3.2.2, mas só 
está presente se a fragmentação for necessária. Supondo que ele seja o único cabeçalho de extensão presente, 
então o campo PróxCab do cabeçalho IPv6 teria o valor 44, que é o valor atribuído para indicar o cabeçalho 
de fragmentação. O campo PróxCab do próprio cabeçalho de fragmentação contém um valor que descreve 
o cabeçalho seguinte a ele. Novamente, supondo que nenhum outro cabeçalho de extensão esteja presente, 
então o próximo cabeçalho poderia ser o cabeçalho TCP o que resulta em PróxCab contendo o valor 6, assim 
como aconteceria no campo Protocolo do IPv4. Se o cabeçalho de fragmentação fosse seguido de, digamos, 
um cabeçalho de autenticação, então o campo PróxCab do cabeçalho de fragmentação teria o valor 51. 


Autoconfiguração 
Embora o crescimento da Internet tenha sido impressionante, um fator que inibiu a aceitação mais rápida 
da tecnologia é o fato de que conectar-se à Internet, normalmente, exigia uma grande habilidade com 
administração de sistemas. Em particular, cada host conectado à Internet precisa ser configurado 
com certa quantidade mínima de informação, como um endereço IP válido, uma máscara de sub-rede para 
o enlace ao qual está conectado e o endereço de um servidor de nomes. Assim, não era possível desembru- 
lhar um computador novo e conectá-lo à Internet sem alguma configuração prévia. Um objetivo do IPv6, 
portanto, é melhorar o suporte para a autoconfiguração, também chamada de operação plug-and-play. 

Como vimos na Seção 3.2.7, a autoconfiguração é possível para o IPv4, mas isso depende da existência 
de um servidor que esteja configurado para entregar endereços e outras informações de configuração 
aos clientes do Dynamic Host Configuration Protocol (DHCP). O formato de endereços maior no IPv6 
ajuda a oferecer uma nova forma útil de autoconfiguração, chamada autoconfiguração sem estado, que 
não requer um servidor. 

Lembre de que os endereços unicast do IPv6 são hierárquicos, e que a parte menos significativa é o 
ID de interface. Assim, podemos subdividir o problema de autoconfiguração em duas partes: 


1. Obter um ID de interface que seja exclusivo no enlace ao qual o host está conectado. 
2. Obter o prefixo de endereços correto para esta sub-rede. 


Acontece que a primeira parte é muito fácil, pois cada host em um enlace precisa ter um endereço 
exclusivo no nível de enlace. Por exemplo, todos os hosts em uma Ethernet possuem um único ende- 
reço Ethernet de 48 bits. Este pode ser transformado em um endereço válido para uso local ao enlace 
acrescentando o prefixo apropriado da Tabela 4.1 (1111 1110 10) seguido por Os suficientes para compor os 
128 bits. Para alguns dispositivos — por exemplo, impressoras ou hosts em uma pequena rede sem roteador, 


0 8 16 29 31 


Desloca- RES M 


PróxCab Reservado 
mento 


Ident 
FIGURA 4.13 Cabeçalho de extensão do IPv6 relativo à fragmentação. 
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que não se conecte a quaisquer outras redes —, esse endereço pode ser perfeitamente adequado. Aqueles 
dispositivos que precisam de um endereço globalmente válido dependem de um roteador no mesmo enlace 
para anunciar periodicamente o prefixo apropriado para o enlace. Claramente, isso exige que o roteador 
seja configurado com o prefixo de endereços correto e que esse prefixo seja escolhido de tal forma que haja 
espaço suficiente no final (por exemplo, 48 bits) para anexar um endereço apropriado do nível de enlace. 
A capacidade de embutir endereços do nível de enlace com até 48 bits nos endereços IPv6 foi um dos 
motivos para escolher um tamanho de endereço tão grande. Os 128 bits permitem não apenas a inserção, mas 
também deixa bastante espaço para a hierarquia multinível do endereçamento, sobre a qual já discutimos. 


TRADUÇÃO DE ENDEREÇOS DE REDE 


Embora o IPv6 tenha sido motivado por uma preocupação de que o uso crescente do IP levaria ao 
esgotamento do espaço de endereços, outra tecnologia tornou-se popular como um meio de economizar 

o espaço de endereços IP Essa tecnologia é a tradução de endereços de rede (NAT — Network Address 
Translation), e seu uso difundido é uma razão principal para a implantação do IPv6 ainda continuar em seus 
primeiros estágios. A técnica de NAT é vista por alguns como “arquitetonicamente impura”, mas também é 
um fato da vida das redes que não pode ser ignorado. 

A ideia básica por trás da técnica de NAT é que todos os hosts que poderiam se comunicar uns com os 
outros pela Internet não precisam ter endereços globalmente exclusivos. Em vez disso, um host poderia 
receber um “endereço privado” que não necessariamente é globalmente exclusivo, mas é exclusivo dentro 
de algum escopo mais limitado — por exemplo, dentro da rede corporativa onde o host reside. O número de 
rede de classe A 10 normalmente é usado para essa finalidade, pois esse número de rede foi atribuído à 
ARPANET e não está mais em uso como um endereço globalmente exclusivo. Enquanto o host se comunica 
apenas com outros hosts na rede corporativa, um endereço localmente exclusivo é o suficiente. Se ele quiser 
se comunicar com um host fora da rede corporativa, ele faz isso por meio de uma caixa NAT um dispositivo 
que é capaz de traduzir o endereço privado usado pelo host para algum endereço globalmente exclusivo 
atribuído à caixa NAT. Como é provável que um pequeno subconjunto dos hosts na empresa façam uso dos 
serviços da caixa NAT em qualquer momento, a caixa NAT poderia ser capaz de trabalhar com um pequeno 
conjunto de endereços globalmente exclusivos, muito menor do que o número de endereços que seriam 
necessários se cada host na corporação tivesse um endereço globalmente exclusivo. 

Assim, podemos imaginar uma caixa NAT recebendo pacotes IP de um host dentro da corporação e 
traduzindo o endereço IP de origem de algum endereço privado (digamos, 10.0.1.5) para um endereço 
globalmente exclusivo (digamos, 171.69.210.246). Quando os pacotes retornam do host remoto endereçados 
para 171.69.210.246, a caixa NAT traduz o endereço de destino para 10.0.1.5 e encaminha o pacote para o host. 

A principal desvantagem da técnica de NAT é que ela quebra uma conjectura chave do modelo de serviço 
do IP — que todos os nós possuem endereços globalmente exclusivos. Acontece que muitas aplicações 
e protocolos contam com essa suposição. Alguns protocolos que são executados sobre o IP (por exemplo, 
protocolos de aplicação como FTP) transportam endereços IP em suas mensagens. Esses endereços 
também precisam ser traduzidos por uma caixa NAT se o protocolo da camada superior tiver que funcionar 
corretamente e, assim, as caixas NAT tornam-se muito mais complexas do que simples tradutores de 
cabeçalhos IP Elas potencialmente precisam entender um número cada vez maior de protocolos da camada 
superior. Isso, por sua vez, apresenta um obstáculo para a implantação de novas aplicações. 

Ainda mais sério é o fato de a técnica de NAT tornar difícil para um dispositivo externo iniciar uma 
conexão com um dispositivo no lado privado da rede com NAT, pois, na ausência de um mapeamento 
estabelecido no dispositivo de NAT, não há um endereço público para o qual enviar a solicitação de conexão. 
Essa situação complicou a implantação de muitas aplicações, como Voz sobre IP (VoIP). 

Provavelmente é seguro dizer que as redes ficariam melhores sem NAT, mas seu desaparecimento parece 
improvável. Embora a implantação generalizada do IPv6 provavelmente ajude, a técnica de NAT agora é 
popular por diversos outros motivos, além de sua finalidade original. Por exemplo, fica mais fácil trocar de 
provedor se a sua rede interna inteira tiver endereços IP (privados) que não possuem relação alguma com o 
espaço de endereços do provedor. E, embora as caixas NAT não possam ser consideradas uma solução real 
para ameaças de segurança, o fato de que os endereços por trás de uma caixa NAT não são têm significado 
globalmente oferece certo nível de proteção contra ataques simples. Será interessante ver como a técnica 
de NAT será avaliada no futuro, quando a implantação do IPv6 ganhar impulso. 
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Capacidades avançadas de roteamento 

Outro dos cabeçalhos de extensão do IPv6 é o cabeçalho de roteamento. Na ausência desse cabeçalho, o 
roteamento no IPv6 difere muito pouco daquele do IPv4 com CIDR. O cabeçalho de roteamento contém 
uma lista de endereços IPv6 que representam nós ou áreas topológicas que o pacote deverá visitar a 
caminho do seu destino. Uma área topológica pode ser, por exemplo, a rede do provedor de backbone. 
Especificar que os pacotes precisam visitar essa rede seria um modo de implementar a seleção de 
provedor para cada pacote. Assim, um host poderia dizer que deseja que alguns pacotes sigam por um 
provedor que é barato, outros por um provedor que oferece alta confiabilidade e ainda outros por 
um provedor em que o host confia para fornecer segurança. 

Para fornecer a capacidade de especificar entidades topológicas em vez de nós individuais, o IPv6 define 
um endereço de anycast. Um endereço de anycast é atribuído a um conjunto de interfaces, e os pacotes 
enviados a esse endereço irão para a “mais próxima” dessas interfaces, com a relação de proximidade sendo 
determinada pelos protocolos de roteamento. Por exemplo, todos os roteadores de um provedor de back- 
bone poderiam receber um único endereço de anycast, que seria usado no cabeçalho de roteamento. 

Também se espera que o endereço de anycast e o cabeçalho de roteamento sejam usados 
para fornecer um suporte avançado ao roteamento para hosts móveis. Os mecanismos detalhados para 
fornecer esse suporte ainda estão sendo definidos. 


Outros recursos 

Conforme mencionamos no início desta seção, a principal motivação por trás do desenvolvimento 
do IPv6 foi dar suporte ao crescimento contínuo da Internet. Porém, quando o cabeçalho IP teve que 
ser modificado em razão dos endereços, a porta estava aberta para uma grande variedade de outras 
mudanças, duas das quais já descrevemos — autoconfiguração e roteamento direcionado pela origem. 
O IPv6 inclui vários recursos adicionais, a maioria deles abordada em outras partes deste livro — a 
mobilidade é discutida na Seção 4.4.2, a segurança é o assunto do Capítulo 8 e um novo modelo de 
serviço, proposto para a Internet, é descrito na Seção 6.5. É interessante observar que, na maioria dessas 
áreas, as capacidades do IPv4 e do IPv6 se tornaram praticamente indistintas, de modo que o principal 
propulsor para o IPv6 continua sendo a necessidade de endereços maiores. 


4.2 Multicast 


Como vimos no Capítulo 2, as redes de acesso múltiplo como Ethernet implementam o multicast em 
hardware. Porém, existem aplicações que precisam de uma capacidade de multicast mais ampla, que seja 
eficaz na escala das inter-redes. Por exemplo, quando uma estação de rádio é transmitida pela Internet, 
os mesmos dados precisam ser enviados para todos os hosts onde um usuário tenha sintonizado nessa 
estação. Nesse exemplo, a comunicação é de um para muitos. Outros exemplos de aplicações um para 
muitos incluem a transmissão das mesmas notícias, preços de ações da bolsa de valores ou atualizações 
de software para vários hosts. Há também aplicações cuja comunicação é muitos para muitos, como 
na teleconferência multimídia, jogos com vários jogadores on-line ou simulações distribuídas. Nesses 
casos, os membros de um grupo recebem dados de vários emissores, normalmente uns dos outros. A 
partir de qualquer emissor em particular todos eles recebem os mesmos dados. 

A comunicação IP normal, em que cada pacote precisa ser endereçado e enviado a um único host, 
não é bem adequada para tais aplicações. Se uma aplicação tem dados para enviar a um grupo, ela teria 
que enviar um pacote separado com os dados idênticos a cada membro do grupo. Essa redundância 
consome mais largura de banda do que o necessário. Além disso, o tráfego redundante não é distribuído 
uniformemente, mas é focalizado em torno do host emissor, e pode facilmente exceder a capacidade 
do host emissor e das redes e roteadores vizinhos. 

Para dar melhor suporte à comunicação muitos para muitos e um para muitos, o IP oferece um 
mecanismo de multicast em nível de IP semelhante ao multicast em nível de enlace fornecido pelas redes 
de acesso múltiplo, como Ethernet, conforme vimos no Capítulo 2. Agora que estamos introduzindo o 
conceito de multicast para IP também precisamos de um termo para o serviço um para um tradicional 
do IP que foi descrito até aqui: esse serviço é chamado de unicast. 
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O modelo multicast IP básico é um modelo muitos para muitos baseado em grupos multicast, onde 
cada grupo tem seu próprio endereço IP multicast. Os hosts que são membros de um grupo recebem 
cópias de quaisquer pacotes enviados ao endereço multicast desse grupo. Um host pode estar em vários 
grupos, e pode se juntar e sair de grupos livremente após informar ao seu roteador local por meio de 
um protocolo que veremos em breve. Assim, enquanto pensamos em endereços unicast como sendo 
associados a um nó ou uma interface, os endereços multicast são associados a um grupo abstrato, cujos 
membros mudam dinamicamente todo o tempo. Além disso, o modelo de serviço original de multicast 
IP permite que qualquer host envie tráfego multicast a um grupo; ele não precisa ser um membro do 
grupo, e pode haver qualquer quantidade desses emissores para um determinado grupo. 

Usando o multicast IP para enviar um pacote idêntico a cada membro do grupo, um host envia uma 
única cópia do pacote endereçada ao endereço de multicast do grupo. O host emissor não precisa saber o 
endereço IP unicast individual de cada membro do grupo porque, conforme veremos, esse conhecimento 
é distribuído entre os roteadores na inter-rede. De modo semelhante, o host emissor não precisa enviar 
várias cópias do pacote, pois os roteadores farão cópias sempre que tiverem que encaminhar o pacote 
por mais de um enlace. Em comparação com o uso do IP unicast para entregar os mesmos pacotes a 
muitos receptores, o multicast IP é mais escalável, pois elimina o tráfego redundante (pacotes) que teria 
sido enviado muitas vezes pelos mesmos enlaces, especialmente aqueles próximos do host emissor. 

O multicast muitos para muitos original do IP tem sido suplementado com suporte a uma forma de 
multicast um para muitos. Nesse modelo de multicast um para muitos, chamado multicast de origem es- 
pecífica (SSM — Source-Specific Multicast), um host receptor especifica tanto um grupo de multicast como 
um host emissor específico. O host receptor, então, receberia tráfego multicast endereçados ao grupo es- 
pecificado, mas somente se eles forem do emissor especificado. Muitas aplicações de multicast da Internet 
(por exemplo, transmissões de rádio) se encaixam no modelo SSM. Comparado com o SSM, o modelo 
muitos para muitos original do IP às vezes, é chamado de multicast de qualquer origem (ASM -Any Source 
Multicast). 

Um host sinaliza seu desejo de juntar-se ou sair de um grupo multicast comunicando-se com seu 
roteador local por meio de um protocolo especial usado apenas para essa finalidade. No IPv4, esse 
protocolo é o protocolo de gerenciamento de grupos inter-rede (IGMP - Internet Group Management 
Protocol); no IPv6, ele é a descoberta de ouvinte multicast (MLD - Multicast Listener Discovery). O 
roteador, então, é responsável por fazer com que o multicast opere corretamente com relação a esse 
host. Como um host pode deixar de sair de um grupo de multicast quando deveria (após uma parada 
do sistema ou outra falha, por exemplo), o roteador examina periodicamente a LAN para determinar 
quais grupos ainda são de interesse para os hosts conectados. 


4.2.1 Endereços multicast 


O IP tem uma subfaixa de seu espaço de endereços reservada para endereços multicast. No IPv4, esses 
endereços são atribuídos no espaço de endereços de classe D, e o IPv6 também tem uma parte de seu 
espaço de endereços (ver Tabela 4.1) reservada para endereços de grupos multicast. Algumas subfaixas 
das faixas de multicast são reservadas para multicast intradomínio, de modo que podem ser reutilizadas 
independentemente por diferentes domínios. 

Assim, existem 28 bits de endereços multicast possíveis no IPv4 quando ignoramos o prefixo com- 
partilhado por todos os endereços multicast. Isso apresenta um problema quando se tenta tirar proveito 
do multicast em hardware em uma rede local (LAN). Vejamos o caso da rede Ethernet. Os endereços 
multicast da Ethernet têm apenas 23 bits quando ignoramos seu prefixo compartilhado. Em outras 
palavras, para tirar proveito do multicast Ethernet, o IP precisa mapear endereços multicast IP de 
28 bits para endereços multicast Ethernet de 23 bits. Isso é implementado tomando os 23 bits menos 
significativos de qualquer endereço multicast IP para usar como seu endereço multicast Ethernet e 
ignorando os 5 bits mais significativos. Assim, 32 (2º) endereços IP são mapeados para cada um dos 
endereços Ethernet. 

Quando um host em uma rede Ethernet se junta a um grupo de multicast IP ele configura sua in- 
terface Ethernet para receber quaisquer pacotes com o endereço multicast Ethernet correspondente. 
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Infelizmente, isso faz com que o host receptor receba não apenas o tráfego multicast que ele desejava, 
mas também o tráfego enviado a qualquer um dos outros 31 grupos de multicast IP que são mapeados 
para o mesmo endereço Ethernet, caso eles sejam roteados para essa Ethernet. Portanto, o IP no host 
receptor precisa examinar o cabeçalho IP de qualquer pacote multicast para determinar se o pacote 
realmente pertence ao grupo desejado. Resumindo, a divergência dos tamanhos de endereço multicast 
significa que o tráfego multicast pode colocar um peso adicional sobre os hosts que não estão sequer 
interessados no grupo ao qual o tráfego foi enviado. Felizmente, em algumas redes comutadas (como a 
Ethernet comutada), esse problema pode ser aliviado por esquemas nos quais os switches reconhecem 
pacotes indesejados e os descartam. 

Uma questão complicada é como emissores e receptores descobrem quais endereços multicast 
usar em primeiro lugar. Isso normalmente é tratado por mecanismos fora da banda, e existem algumas 
ferramentas bastante sofisticadas para permitir que endereços de grupo sejam anunciados na Internet. 
Um exemplo é sdr, discutido na Seção 9.2.1. 


4.2.2 Roteamento multicast (DVMRP, PIM, MSDP) 


As tabelas de encaminhamento unicast de um roteador indicam, para qualquer endereço IP qual enlace 
deve ser usado para encaminhar o pacote unicast. Para dar suporte ao multicast, um roteador precisa 
ter também tabelas de encaminhamento multicast que indicam, com base no endereço multicast, quais 
enlaces — possivelmente mais de um — devem ser usados ao encaminhar o pacote multicast (o roteador 
duplica o pacote se ele tiver que ser encaminhado por vários enlaces). Assim, onde as tabelas de encami- 
nhamento unicast especificam coletivamente um conjunto de caminhos, as tabelas de encaminhamento 
multicast especificam coletivamente um conjunto de árvores: árvores de distribuição multicast. Além 
disso, para dar suporte ao multicast de origem específica (e, no fim das contas, para alguns tipos de 
multicast de qualquer origem), as tabelas de encaminhamento multicast precisam indicar quais enlaces 
usar com base na combinação do endereço multicast e do endereço IP (unicast) de origem, novamente 
especificando um conjunto de árvores. 

O roteamento multicast é o processo pelo qual as árvores de distribuição multicast são determinadas 
ou, mais precisamente, o processo pelo qual as tabelas de encaminhamento multicast são montadas. 
Assim como no roteamento unicast, não é suficiente que um protocolo de roteamento multicast “fun- 
cione”; ele deve também escalar razoavelmente bem à medida que a rede cresce, e precisa acomodar a 
autonomia de diferentes domínios de roteamento. 


DVMRP 

O roteamento por vetor de distâncias, que discutimos na Seção 3.3.2 para unicast, pode ser estendido 
para dar suporte ao multicast. O protocolo resultante é chamado protocolo de roteamento multicast por 
vetor de distâncias, ou DVMRP (Distance Vector Multicast Routing Protocol). O DVMRP foi o primeiro 
protocolo de roteamento multicast a ter uso difundido. 

Lembre-se de que, no algoritmo por vetor de distâncias, cada roteador mantém uma tabela de triplas 
(Destino, Custo, PróxSalto) e troca uma lista de pares (Destino, Custo) com seus vizinhos conectados dire- 
tamente. A extensão desse algoritmo para dar suporte ao multicast é um processo em dois estágios. Pri- 
meiro, criamos um mecanismo de broadcast que permite que um pacote seja encaminhado para todas as 
redes na inter-rede. Segundo, precisamos refinar esse mecanismo de modo que ele volte podando 
as redes que não possuem hosts pertencentes ao grupo de multicast. Consequentemente, o DVMRP é 
um dos vários protocolos de roteamento multicast descritos como protocolos do tipo inundar e podar 
(flood-and-prune). 

Dada uma tabela de roteamento unicast, cada roteador sabe que o caminho mais curto atual para 
determinado destino passa por PróxSalto. Assim, sempre que ele recebe um pacote multicast da origem 
S, o roteador encaminha o pacote para todos os enlaces de saída (exceto aquele em que o pacote chegou) 
se, e somente se, o pacote chegou pelo enlace que está no caminho mais curto para S (ou seja, o pacote 
veio do PróxSalto associado a S na tabela de roteamento). Essa estratégia inunda eficientemente os 
pacotes adiante a partir de S, mas não retorna os pacotes para S formando um ciclo. 
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Existem duas desvantagens principais nessa técnica. A primeira é que ela verdadeiramente inunda 
a rede; ela não tem mecanismos para evitar LANs que não possuem membros no grupo de multicast. 
Resolvemos esse problema a seguir. A segunda limitação é que determinado pacote será encami- 
nhado por uma LAN por cada um dos roteadores conectados a essa LAN. Isso é devido à estratégia de 
encaminhamento dos pacotes por inundação em todos os enlaces diferentes daquele em que o pacote 
chegou, sem considerar se ou não esses enlaces fazem parte da árvore de caminho mais curto cuja raiz 
é a origem. 

A solução para essa segunda limitação é eliminar os pacotes de broadcast duplicados que são gerados 
quando mais de um roteador é conectado a determinada LAN. Um modo de fazer isso é designar um 
roteador como o roteador pai para cada enlace, relativo à origem, de modo que apenas o roteador 
pai tem permissão para encaminhar pacotes multicast dessa origem pela LAN. O roteador que tem o 
caminho mais curto para a origem S é selecionado como pai; um empate entre dois roteadores seria 
resolvido considerando qual roteador tem o menor endereço. Determinado roteador pode descobrir se 
é o pai para a LAN (novamente em relação a cada origem possível) com base nas mensagens por vetor 
de distâncias que ele troca com seus vizinhos. 

Observe que esse refinamento requer que cada roteador mantenha, para cada origem, um bit para 
cada um dos enlaces nele incidentes, indicando se ele é ou não o pai para esse par origem/enlace. 
Lembre-se de que, no ambiente de inter-redes, uma origem é uma rede, e não um host, pois um roteador 
da inter-rede está interessado apenas em encaminhar pacotes entre redes. O mecanismo resultante, às 
vezes, é chamado de broadcast pelo caminho reverso (RPB — Reverse Path Broadcast) ou encaminhamento 
pelo caminho reverso (RPF — Reverse Path Forwarding). O caminho é reverso porque estamos consideran- 
do o caminho mais curto para a origem ao tomar nossas decisões de encaminhamento, em comparação 
com o roteamento unicast, que procura o caminho mais curto para determinado destino. 

O mecanismo do RPB que descrevemos implementa o broadcast pelo caminho mais curto. Agora, 
queremos podar o conjunto de redes que recebe cada pacote endereçado ao grupo G para excluir aquelas 
que não possuem hosts membros de G. Isso pode ser feito em dois estágios. Primeiro, precisamos reco- 
nhecer quando uma rede folha não possui membros do grupo. É fácil determinar se uma rede é uma 
folha — se o roteador pai, conforme descrevemos, for o único roteador na rede, então a rede é uma folha. 
Para determinar se quaisquer membros do grupo residem na rede, é preciso fazer com que cada host 
que seja um membro do grupo G anuncie periodicamente esse fato pela rede, conforme explicamos 
em nossa descrição anterior do multicast por estado do enlace. O roteador, então, usa essa informação 
para decidir se deve ou não encaminhar um pacote multicast endereçado a G por essa LAN. 

O segundo estágio é propagar essa informação de “nenhum membro de G aqui” pela árvore de 
caminho mais curto, na direção da raiz. Para isso, o roteador deve acrescentar aos pares (Destino, Custo) 
que envia para seus vizinhos o conjunto de grupos dos quais a rede folha está interessada em receber 
pacotes multicast. Essa informação pode então ser propagada de um roteador para outro, de modo 
que, para cada um de seus enlaces, determinado roteador saiba para quais grupos ele deve encaminhar 
pacotes multicast. 

Observe que a inclusão de toda essa informação na atualização do roteamento é algo muito dis- 
pendioso de ser feito. Portanto, na prática, essa informação é trocada somente quando alguma origem 
começa a enviar pacotes para esse grupo. Em outras palavras, a estratégia é usar RPB, que acrescenta 
uma pequena quantidade de overhead ao algoritmo básico por vetor de distâncias, até que um endereço 
de multicast em particular se torne ativo. Nesse momento, os roteadores que não estão interessados em 
receber pacotes endereçados a esse grupo se manifestam, e essa informação é propagada aos outros 
roteadores. 


PIM-SM 

O multicast independente de protocolo, ou PIM (Protocol Independent Multicast), foi desenvolvido em 
resposta aos problemas de escalabilidade dos protocolos de roteamento multicast anteriores. Em parti- 
cular, foi reconhecido que os protocolos existentes não apresentavam boa escalabilidade em ambientes 
onde uma proporção relativamente baixa de roteadores deseja receber tráfego para certo grupo. Por 
exemplo, enviar tráfego para todos os roteadores via broadcast até que eles peçam explicitamente para 
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serem removidos da distribuição não é uma boa escolha de projeto se a maioria dos roteadores não 
quiser receber o tráfego em primeiro lugar. Essa situação é tão comum que o PIM divide o espaço do 
problema em modo esparso e modo denso, onde esparso e denso referem-se à proporção de roteadores 
que desejarão receber os pacotes multicast. O PIM em modo denso (PIM-DM) usa um algoritmo de 
inundar e podar como o DVMRP e sofre do mesmo problema de escalabilidade. O modo esparso do 
PIM (PIM-SM) tornou-se o protocolo de roteamento multicast dominante e é o foco de nossa discussão 
aqui. O aspecto “independente de protocolo” do PIM, a propósito, refere-se ao fato de que, diferente de 
protocolos anteriores como DVMRP o PIM não depende de qualquer tipo em particular de roteamento 
unicast — ele pode ser usado com qualquer protocolo de roteamento unicast, conforme veremos em 
seguida. 

No PIM-SM, os roteadores se juntam explicitamente à árvore de distribuição multicast, usando 
mensagens do protocolo PIM conhecidas como mensagens de associação, ou Join. Observe o contraste 
com a técnica do DVMRP de primeiro criar uma árvore de broadcast e depois podar os roteadores não 
interessados. A questão que surge é para onde enviar essas mensagens de Join, pois, afinal, qualquer 
host (e qualquer número de hosts) poderia enviar dados para o grupo de multicast. Para resolver isso, o 
PIM-SM atribui a cada grupo um roteador especial, conhecido como ponto de encontro (RP — Rendezvous 
Point). Em geral, diversos roteadores em um domínio são configurados para serem candidatos a RP e o 
PIM-SM define um conjunto de procedimentos pelo qual todos os roteadores em um domínio podem 
entrar em acordo sobre o roteador a ser usado como RP para determinado grupo. Esses procedimentos 
são um tanto complexos, pois devem lidar com uma grande variedade de cenários, como a falha 
de um RP candidato e o particionamento de um domínio em duas redes separadas, devido a uma série de 
falhas do enlace ou do nó. Para o restante desta discussão, consideramos que todos os roteadores em 
um domínio conhecem o endereço IP unicast do RP para determinado grupo. 

Uma árvore de encaminhamento multicast é montada como resultado de roteadores enviando 
mensagens de Join ao RP O PIM-SM permite que dois tipos de árvores sejam construídas: uma árvore 
compartilhada, que pode ser usada por todos os emissores, e uma árvore de origem específica, que só 
pode ser usada por um host emissor específico. O modo de operação normal cria a árvore compartilhada 
primeiro, seguida por uma ou mais árvores específicas da origem, se houver tráfego suficiente para 
justificar isso. Como a montagem de árvores instaura um estado nos roteadores ao longo da árvore, é 
importante que o padrão seja haver apenas uma árvore para um grupo, e não uma para cada emissor 
em um grupo. 

Quando um roteador envia uma mensagem Join ao RP para um grupo G, ela é enviada usando a 
transmissão unicast normal do IP Isso é ilustrado na Figura 4.14(a), em que o roteador R4 está enviando 
um Join ao ponto de encontro para algum grupo. A mensagem Join inicial é um “curinga”; ou seja, ela 
se aplica a todos os emissores. Uma mensagem Join claramente precisa passar por alguma sequência 
de roteadores antes de alcançar o RP (por exemplo, R2). Cada roteador ao longo do caminho examina o 
Join e cria uma entrada da tabela de encaminhamento à árvore compartilhada, chamada entrada (*, G), 
onde * significa “todos os emissores”. Para criar a entrada da tabela de encaminhamento, ele examina a 
interface em que o Join chegou e marca essa interface como aquela para onde deve encaminhar pacotes 
de dados para esse grupo. Depois, ele determina qual interface usará para encaminhar o Join para o 
RP Essa será a única interface aceitável para receber pacotes enviados para esse grupo. Em seguida, 
ele encaminha o Join para o RP Por fim, a mensagem chega ao RP completando a construção do ramo 
da árvore. A árvore compartilhada, construída dessa forma, aparece como uma linha sólida do RP até 
R4 na Figura 4.14(a). 

À medida que mais roteadores enviam Joins ao RP ele fazem com que novos ramos sejam acres- 
centados à árvore, conforme ilustra a Figura 4.14(b). Observe que, nesse caso, o Join só precisa viajar 
até R2, que pode acrescentar o novo ramo à árvore simplesmente acrescentando uma nova interface de 
saída para a entrada da tabela de encaminhamento criada para esse grupo. R2 não precisa encaminhar 
o Join ao RP Observe também que o resultado final desse processo é a montagem de uma árvore cuja 
raiz é o RP 

Neste ponto, suponha que um host queira enviar uma mensagem ao grupo. Para fazer isso, ele cons- 
trói um pacote com o endereço do grupo de multicast apropriado como seu destino e o envia para um 
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RP=Ponto de encontro (Rendezvous Point) 
Árvore compartilhada 
———— Árvore de origem específica para a origem R1 


FIGURA 4.14 Operação do PIM: (a) R4 envia Join para RP e se junta à árvore compartilhada; (b) R5 se junta à árvore compartilhada; 
(c) RP monta a árvore de origem específica para R1 enviando Join para R1; (d) R4 e R5 montam a árvore de origem específica para R1 
enviando Joins para R1. 


roteador em sua rede local, conhecido como roteador designado (DR - Designated Router). Suponha 
que o DR seja R1 na Figura 4.14. Não há um estado para esse grupo de multicast entre R1 e o RP neste 
ponto, de modo que, em vez de simplesmente encaminhar o pacote de multicast, R1 o envia para o RP 
via túnel. Ou seja, R1 encapsula o pacote multicast dentro de uma mensagem de registro (Register) do 
PIM, que ele envia ao endereço IP unicast do RP Assim como uma extremidade do túnel do tipo des- 
crito na Seção 3.2.9, o RP recebe o pacote endereçado a ele, examina o payload da mensagem Register 
e encontra dentro um pacote IP endereçado ao endereço multicast desse grupo. O RP é claro, sabe o 
que fazer com esse pacote — ele o envia à árvore compartilhada da qual o RP é a raiz. No exemplo da 
Figura 4.14, isso significa que o RP envia o pacote para R2, que é capaz de encaminhá-lo para R4 e R5. A 
entrega completa de um pacote de R1 para R4 e R5 aparece na Figura 4.15. Vemos o pacote enviado via 
túnel trafegando de R1 ao RP com um cabeçalho IP extra, contendo o endereço unicast de RP e depois 
o pacote multicast endereçado a G seguindo pela árvore compartilhada até R4 e R5. 

Neste ponto, poderíamos ser tentados a declarar que tivemos sucesso, pois todos os hosts podem 
enviar mensagens para todos os receptores dessa forma. Porém, existe alguma ineficiência no uso 
da largura de banda e no custo de processamento para o encapsulamento e desencapsulamento de 
pacotes a caminho do RP de modo que o RP injeta o conhecimento sobre esse grupo nos roteadores 
intermediários, para que o tunelamento possa ser evitado. Ele envia uma mensagem de Join para o 
host emissor (Figura 4.14(c)). À medida que esse Join viaja até o host, ele faz com que os roteadores ao 
longo do caminho (R3) aprendam sobre a existência do grupo, de modo que será possível ao DR enviar 
o pacote para o grupo como pacotes multicast nativos (ou seja, sem o uso de túnel). 

Um detalhe importante a observar nesse estágio é que a mensagem Join enviada pelo RP ao host 
emissor é específica a esse servidor, enquanto as anteriores enviadas por R4 e R5 se aplicavam a todos 
os emissores. Assim, o efeito do novo Join é criar um estado de emissor específico nos roteadores entre 
a origem identificada e o RP Isso é conhecido como estado (S, G), pois se aplica a um emissor (source) 
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FIGURA 4.15 Entrega de um pacote ao longo de uma árvore 
compartilhada. R1 envia o pacote por um túnel para o RP, 
que o encaminha pela árvore compartilhada para R4 e R5. 





para um grupo, e contrasta com o estado (*, G) que foi instaurado entre os receptores e o RP que se 
aplica a todos os emissores. Assim, na Figura 4.14(c), vemos uma rota de origem específica de R1 a 
RP (indicada pela linha tracejada) e uma árvore que é válida para todos os emissores do RP aos receptores 
(indicada pela linha sólida). 

A próxima otimização possível é substituir a árvore compartilhada inteira por uma árvore de ori- 
gem específica. Isso é desejável porque o caminho do emissor ao receptor por meio do RP poderia 
ser significativamente maior do que o caminho mais curto possível. Isso, novamente, é provável de ser 
disparado por uma alta taxa de dados sendo observada vindo de algum emissor. Nesse caso, o roteador 
na extremidade da árvore na direção do fluxo — digamos, R4 em nosso exemplo — envia um Join de 
origem específica em direção à origem. À medida que ele percorre o caminho mais curto até a origem, 
os roteadores ao longo do caminho criam o estado (S, G) para essa árvore, e o resultado é uma árvore 
que tem sua raiz na origem, em vez do RP Supondo que tanto R4 como R5 migrem para a árvore de 
origem específica, acabaríamos com a árvore mostrada na Figura 4.14(d). Observe que essa árvore não 
envolve mais o RP de forma alguma. Removemos a árvore compartilhada dessa figura para simplificar 
o diagrama, mas na realidade todos os roteadores com receptores para um grupo precisam permanecer 
na árvore compartilhada, caso novos emissores apareçam. 

Agora podemos ver por que o PIM é independente de protocolo. Todos os seus mecanismos para 
criar e manter árvores tiram proveito do roteamento unicast sem depender de qualquer protocolo de 
roteamento unicast em particular. A formação de árvores é inteiramente determinada pelos caminhos 
que as mensagens de Join seguem, que é determinado pela escolha dos caminhos mais curtos feita pelo 
roteamento unicast. Assim, para ser exato, o PIM é “independente de protocolo de roteamento unicast”, 
em comparação com o DVMRP Observe que o PIM é fortemente associado ao Internet Protocol — ele 
não é independente de protocolo em termos de protocolos da camada de rede. 

O projeto do PIM-SM novamente ilustra os desafios na criação de redes escaláveis e como a es- 
calabilidade, às vezes, confronta-se com algum tipo de otimização. A árvore compartilhada certamente 
é mais escalável do que uma árvore de origem específica, no sentido que reduz a quantidade total de 
estados nos roteadores para um valor da ordem do número de grupos, em vez do número de emissores 
vezes o número de grupos. Porém, a árvore de origem específica provavelmente será necessária para 
obter um roteamento eficiente e um uso eficaz da largura de banda do enlace. 


Multicast interdomínios (MSDP) 

O PIM-SM tem algumas deficiências significativas quando se trata de multicast interdomínios. Em 
particular, a existência de um único RP para um grupo vai contra o princípio de que os domínios são 
autônomos. Para determinado grupo de multicast, todos os domínios participantes seriam dependentes 
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do domínio onde o RP está localizado. Além disso, se houver um grupo multicast em particular para o 
qual o emissor e alguns receptores compartilhem um único domínio, o tráfego de multicast ainda teria 
que ser roteado inicialmente do emissor para esses receptores através de um domínio qualquer que 
tenha o RP para esse grupo de multicast. Consequentemente, o protocolo PIM-SM normalmente não 
é usado entre os domínios, somente dentro de um domínio. 

Para estender o multicast por meio dos domínios usando PIM-SM, o Protocolo Multicast de Descoberta 
de Origem (MSDP — Multicast Source Discovery Protocol) foi criado. O MSDP é usado para conectar diferen- 
tes domínios — cada um executando PIM-SM internamente, com seus próprios RPs — conectando os RPs 
dos diferentes domínios. Cada RP tem um ou mais pares MSPD que atuam como RPs em outros domínios. 
Cada grupo de pares MSDP é conectado por uma conexão TCP (Seção 5.2) sobre a qual o protocolo MSDP 
é executado. Juntos, todos os pares MSDP para determinado grupo multicast formam uma espécie de 
malha que é usada como rede de broadcast. Mensagens MSDP são enviadas por broadcast pela malha de 
pares RPs usando o algoritmo Reverse Path Broadcast (RPB) que discutimos no contexto do DVMRP 

Que informação o MSDP envia por broadcast pela malha de RPs? Não é a informação sobre participa- 
ção de memrbos em grupos; quando um host se junta a um grupo, o mais distante que essa informação 
fluirá é o RP do seu próprio domínio. Em vez disso, é a informação sobre a origem — o emissor multicast. 
Cada RP conhece as origens em seu próprio domínio, pois recebe uma mensagem de Register sempre 
que surge uma nova origem. Cada RP usa periodicamente o MSDP para enviar mensagens de Source 
Active (origem ativa) via broadcast aos seus pares, fornecendo o endereço IP da origem, o endereço do 
grupo de multicast e o endereço IP do RP de onde a mensagem está vindo. 

Se um par MSDP atuando como RP recebe um desses broadcasts e tem receptores ativos para esse 
grupo de multicast, ele envia um Join de origem específica, em nome desse próprio RP para o host de 
origem, como mostrado na Figura 4.16(a). A mensagem de Join cria um ramo da árvore de origem es- 
pecífica para esse RP como mostrado na Figura 4.16(b). O resultado é que cada RP que faz parte da rede 
MSDP e tem receptores ativos para determinado grupo de multicast é adicionado à árvore de origem 
específica da nova origem. Quando um RP recebe tráfego multicast da origem, o RP usa sua árvore 
compartilhada para encaminhar o tráfego multicast aos receptores em seu domínio. 


(a) Domínio A 


3: Join 







1: Domínio B 
Register 


2b: MSDP 
Source active 


(b) Domínio A 
“EB 
E “s, Domínio B 
X 
RP1 -2 No RP2 


Árvore compartilhada 
———— Árvore de origem especifica para a origem SR 


FIGURA 4.16 Operação do MSDP: (a) A origem SR envia um Register ao RP do seu domínio, RP1; em seguida, RP1 envia um Join de 
origem específica ao SR e um Source Active do MSDP ao seu par MSDP no domínio B, RP2; depois, RP2 envia um Join de origem 
específica para SR. (b) Como resultado, RP1 e RP2 estão na árvore de origem específica para a origem SR. 
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Multicast de origem específica (PIM-SSM) 
O modelo de serviço original do PIM era, como os protocolos multicast mais antigos, um modelo muitos 
para muitos. Os receptores se juntavam a um grupo e qualquer host poderia enviar dados ao grupo. 
Porém, foi reconhecido no final da década de 1990 que poderia ser útil incluir um modelo um para 
muitos. Muitas aplicações multicast, afinal, possuem apenas um emissor legítimo, como o palestrante 
em uma conferência sendo transmitida pela Internet. Já vimos que o PIM-SM pode criar árvores de 
caminho mais curto de origem específica como uma otimização depois de usar a árvore compartilhada 
inicialmente. No projeto original do PIM, essa otimização era invisível aos hosts - somente roteadores se 
juntavam a árvores de origem específica. Porém, quando foi reconhecida a necessidade de um modelo 
de serviço um para muitos, decidiu-se tornar a capacidade de roteamento de origem específica do PIM 
-SM disponível explicitamente aos hosts. Acontece que isso exigiu principalmente mudanças no IGMP e 
seu correspondente no IPv6, o MLD, em vez do próprio PIM. A capacidade recém-exposta é atualmente 
conhecida como PIM-SSM (PIM Source-Specific Multicast, ou PIM multicast de origem específica). 

O PIM-SSM introduz um novo conceito, o canal, que é a combinação de um endereço de origem S 
e um endereço de grupo G. O endereço de grupo G se parece com um endereço multicast IP normal, 
e tanto o IPv4 como o IPv6 alocaram subfaixas do espaço de endereços multicast para o SSM. Para 
usar o PIM-SSM, um host especifica o grupo e a origem em uma mensagem de relatório de associação 
(membership report) do IGMP ao seu roteador local. Esse roteador, então, envia uma mensagem Join 
PIM-SM de origem específica em direção à origem, acrescentando assim um ramo para si mesmo na 
árvore de origem específica, conforme descrevemos anteriormente para o PIM-SM “normal”, evitando 
o estágio inteiro da árvore compartilhada. Como a árvore resultante é de origem específica, apenas a 
origem designada pode enviar pacotes nessa árvore. 

A introdução do PIM-SSM trouxe alguns benefícios significativos, principalmente porque existe uma 
demanda relativamente alta pela transmissão multicast um para muitos: 


e Mensagens multicast trafegam mais diretamente para os receptores. 

e O endereço de um canal é efetivamente um endereço de grupo multicast mais um endereço de 
origem. Portanto, dado que certa faixa de endereços de grupo multicast será usada exclusivamente 
para o SSM, vários domínios podem usar o mesmo endereço de grupo multicast independentemente 
e sem conflitos, contanto que o utilizem somente com origens em seus próprios domínios. 

e Como somente a origem especificada pode enviar dados para um grupo SSM, existe menos risco 
de ataques baseados em hosts maliciosos sobrecarregando os roteadores ou receptores com 
tráfego multicast falso. 

e O PIM-SSM pode ser usado entre diversos domínios exatamente como ele é usado dentro de um 
domínio, sem depender de qualquer mecanismo semelhante ao MSDP. 


O SSM, portanto, é um acréscimo muito útil ao modelo de serviço multicast. 


Árvores bidirecionais (BIDIR-PIM) 

Terminamos nossa discussão sobre multicast com outra melhoria no PIM, conhecida como PIM 
bidirecional. O BIDIR-PIM é uma variante recente do PIM-SM que é bem adequada para a transmissão 
multicast muitos para muitos dentro de um domínio, especialmente quando emissores e receptores 
de um grupo podem ser os mesmos, como em uma videoconferência envolvendo várias partes, por 
exemplo. Assim como no PIM-SM, os nós que desejam ser receptores se juntam aos grupos enviando 
mensagens IGMP de relatório de associação (que não devem ser de origem específica) e uma árvore 
compartilhada enraizada no RP é usada para encaminhar pacotes multicast aos receptores. Porém, 
diferente do PIM-SM, a árvore compartilhada também tem ramos para as origens. Isso não faria qualquer 
sentido com a árvore unidirecional do PIM-SM, mas as árvores do BIDIR-PIM são bidirecionais - um 
roteador que recebe um pacote multicast de um ramo mais adiante pode encaminhá-lo para cima ou 
para baixo na árvore, para outros ramos. A rota seguida para entregar um pacote a qualquer receptor em 
particular sobe apenas até o ponto necessário na árvore, antes de descer pelo ramo até esse receptor. 
Veja um exemplo na rota multicast de R1 para R2 na Figura 4.17(b). R4 encaminha um pacote multicast 
abaixo para R2 ao mesmo tempo em que encaminha uma cópia do mesmo pacote acima para R5. 
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FIGURA 4.17 Operação do BIDIR-PIM: (a) R2 e R3 enviam 
Joins para o endereço do RP, que se extinguem quando 
alcançam um roteador no enlace do endereço RP. (b) Um 
pacote multicast de R1 é encaminhado para cima até o enlace 
do endereço RP e para baixo onde quer que cruze o ramo de 
um membro do grupo. 





(b) R5 R6 





Um aspecto surpreendente do BIDIR-PIM é que não é preciso haver realmente um RP Tudo o que 
é preciso é um endereço roteável, que é conhecido como um endereço RP embora ele não precise 
ser o endereço de um RP ou mesmo de uma máquina real. Como isso pode acontecer? Um Join de 
um receptor é encaminhado ao endereço RP até que alcance um roteador com uma interface no 
enlace onde o endereço RP residiria, onde o Join se extingue. A Figura 4.17(a) mostra um Join de R2 
se extinguindo em R5, e um Join de R3 se extinguindo em R6. O encaminhamento ascendente de um 
pacote multicast flui de forma semelhante para o endereço RP até que alcance um roteador com uma 
interface no enlace onde o endereço RP residiria, mas em seguida o roteador encaminha o pacote 
multicast para esse enlace como a última etapa do encaminhamento ascendente, garantindo que 
todos os outros roteadores nesse enlace recebam o pacote. A Figura 4.17(b) ilustra o fluxo do tráfego 
multicast originário de R1. 


ONDE ELES ESTÃO AGORA? 





O DESTINO DOS PROTOCOLOS MULTICAST 

Diversos protocolos multicast IP acabaram desaparecendo desde a publicação em 1991 da tese de doutorado 
de Steve Deering, “Multicast Routing in a Datagram Network” (Roteamento Multicast em uma Rede de 
Datagramas). Na maioria dos casos, o desaparecimento dos mesmos teve algo a ver com escalabilidade. O 
protocolo de multicast clássico mais bem sucedido foi o DVMRP sobre o qual discutimos no início da seção. 
O protocolo Multicast Open Shortest Path First (MOSPF) foi baseado no protocolo de roteamento unicast 
Open Shortest Path First (OSPF). O PIM em modo denso (PIM-DM) tem alguma semelhança com o DVMRB, 
pois também usa uma técnica do tipo inundar e podar; ao mesmo tempo, ele é como o PIM-SM por ser 
independente do protocolo de roteamento unicast utilizado. Todos esses protocolos são mais apropriados 

a um domínio denso (ou seja, um com uma alta proporção de roteadores interessados no multicast). Todos 
esses protocolos apareceram relativamente cedo na história do multicast, alguns antes que os desafios 

de escala fossem totalmente evidentes. Embora eles ainda façam sentido dentro de um domínio quando 
espera-se que os grupos multicast tenham interesse denso, eles raramente são usados hoje, em parte porque 
os roteadores normalmente precisam ter suporte a PIM-SM de qualquer forma. 


(Continua) 


216 REDES DE COMPUTADORES ELSEVIER 


ONDE ELES ESTÃO AGORA? (cont.) 


O método de árvores baseadas em núcleo (CBT — Core-Based Trees) foi outra abordagem multicast, 
proposta aproximadamente na mesma época do PIM. A IETF inicialmente não foi capaz de escolher 
entre as duas técnicas, e tanto o PIM como o CBT foram desenvolvidos como protocolos “experimentais”. 
Porém, o PIM foi mais amplamente adotado pela indústria, e as principais contribuições técnicas do CBT — 
árvores compartilhadas e árvores bidirecionais -, por fim, foram incorporadas ao PIM-SM e ao BIDIR-PIM, 
respectivamente. 

O protocolo multicast de roteador de borda (BGMP - Border Gateway Multicast Protocol) também usa o 
conceito de uma árvore compartilhada bidirecional. No caso do BGMP porém, os nós da árvore são domínios, 
com um dos domínios atuando como a raiz. Em outras palavras, o BGMP opera como o MSDP ao juntar 
domínios para dar suporte a multicast interdomínios. Diferente do MSDP os domínios são livres para escolher 
seus próprios protocolos intradomínio. O BGMP foi proposto pela IETE e apenas alguns anos atrás esperava-se 
que o BGMP substituísse o MSDP como protocolo dominante de roteamento interdomínios. Porém, o BGMP é 
muito complexo e requer a existência de um protocolo que atribua faixas de endereços multicast aos domínios 
para que o BGMP saiba qual domínio é a raiz para determinado endereço. Consequentemente, parece não ter 
havido implementações do BGMP muito menos implantações, no momento em que este livro foi escrito. 





O BIDIR-PIM, portanto, até aqui não pode ser usado entre domínios. Por outro lado, ele tem diversas 
vantagens em relação ao PIM-SM para o multicast muitos para muitos dentro de um domínio: 


e Não existe um processo de registro de origem, pois os roteadores já sabem como rotear um pacote 
multicast para o endereço RP 

e As rotas são mais diretas do que aquelas que usam a árvore compartilhada do PIM-SM, pois elas 
sobem na árvore somente até o ponto necessário, e não até o RP 

e As árvores bidirecionais usam muito menos informação de estado do que as árvores de origem 
específica do PIM-SM, pois nunca existe qualquer estado de origem específica. (Por outro lado, as 
rotas serão maiores do que aquelas das árvores de origem específica.) 

e ORP não pode ser um gargalo, e na realidade nenhum RP real é necessário. 


Uma conclusão a se tirar do fato de que existem tantas técnicas diferentes para o multicast somente 
dentro do PIM é que o multicast é um espaço de problema no qual é difícil encontrar soluções ideais. 
Você precisa decidir quais critérios deseja otimizar (uso de largura de banda, estado do roteador, tama- 
nho do caminho etc.) e a que tipo de aplicação está tentando dar suporte (um para muitos, muitos para 
muitos etc.) antes que possa fazer a escolha sobre o “melhor” modo multicast para a tarefa em mãos. 


4.3 Multiprotocol label switching (MPLS) 


Continuamos nossa discussão das melhorias no IP descrevendo um acréscimo à arquitetura da Internet 
que é muito utilizado, porém em grande parte fica oculto dos usuários finais. A melhoria, chamada 
comutação de rótulos multiprotocolo (MPLS - Multiprotocol Label Switching), combina algumas das 
propriedades dos circuitos virtuais com a flexibilidade e robustez dos datagramas. Por um lado, o 
MPLS é bastante associado à arquitetura baseada em datagramas do Internet Protocol — ele depende 
dos endereços IP e protocolos de roteamento IP para realizar seu trabalho. Por outro lado, roteadores 
habilitados com MPLS também encaminham pacotes examinando rótulos relativamente curtos, de 
tamanho fixo, e esses rótulos possuem escopo local, assim como em uma rede de circuitos virtuais. 
Talvez tenha sido o casamento de duas tecnologias aparentemente opostas que causou uma recepção 
um tanto quanto mista na comunidade de engenharia da Internet. 

Antes de examinarmos como o MPLS funciona, é razoável perguntar “para que ele é bom?” Muitas afir- 
mações foram feitas sobre o MPLS, mas existem três coisas principais para as quais ele é usado hoje: 


e Para habilitar funcionalidades do IP em dispositivos que não possuem a capacidade de 
encaminhar datagramas IP da maneira normal. 
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e Para encaminhar pacotes IP ao longo de rotas explícitas — rotas pré-calculadas que não 
necessariamente correspondem àquelas que os protocolos de roteamento IP selecionariam. 
e Para dar suporte a certos tipos de serviços de rede privada virtual. 


Vale a pena observar que um dos objetivos originais - melhorar o desempenho - não está na lista. Isso 
tem muito a ver com os avanços que foram feitos nos algoritmos de encaminhamento para roteadores 
IP nos últimos anos e com o conjunto complexo de fatores que determinam o desempenho, além do 
processamento de cabeçalho. 

A melhor forma de entender como o MPLS funciona é examinar alguns exemplos de seu uso. Nas 
próximas três seções, veremos exemplos para ilustrar as três aplicações do MPLS mencionadas aqui. 


4.3.1 Encaminhamento baseado no destino 


Uma das publicações mais antigas a introduzir a ideia de adicionar rótulos aos pacotes IP foi um artigo 
de Chandranmenon e Vargese, que descrevia uma ideia chamada índices encadeados. Uma ideia muito 
semelhante agora é implementada nos roteadores habilitados com MPLS. O exemplo a seguir mostra 
como essa ideia funciona. 

Considere a rede na Figura 4.18. Cada um dos dois roteadores no canto direito (R3 e R4) tem uma 
rede a ele conectada, com prefixos 18.1.1/24 e 18.3.3/24. Os roteadores restantes (R1 e R2) possuem 
tabelas de roteamento que indicam qual interface de saída cada roteador usaria quando encaminhasse 
pacotes para uma dessas duas redes. 

Quando o MPLS é habilitado em um roteador, este aloca um rótulo para cada prefixo em sua tabela 
de roteamento e anuncia tanto o rótulo como o prefixo que ele representa aos seus roteadores vizinhos. 
Esse anúncio é transportado no protocolo de distribuição de rótulos (Label Distribution Protocol). Isso 
é ilustrado na Figura 4.19. O roteador R2 alocou o valor de rótulo 15 para o prefixo 18.1.1 e o valor de 
rótulo 16 para o prefixo 18.3.3. Esses rótulos podem ser escolhidos conforme a conveniência do roteador 
que os está alocando e podem ser considerados índices para a tabela de roteamento. Depois de alocar 
os rótulos, R2 anuncia os vínculos dos rótulos aos seus vizinhos; nesse caso, vemos R2 anunciando um 
vínculo entre o rótulo 15 e o prefixo 18.1.1 para R1. O significado desse anúncio é que R2 informou, desta 
forma: “Por favor, adicione o rótulo 15 a todos os pacotes enviados para mim que sejam destinados ao 
prefixo 18.1.1”. R1 armazena o rótulo em uma tabela juntamente com o prefixo que ele representa como 
o rótulo remoto ou de saída para quaisquer pacotes que ele envie a esse prefixo. 

Na Figura 4.19(c), vemos outro anúncio de rótulo do roteador R3 para R2 para o prefixo 18.1.1, e R2 
coloca o rótulo remoto que ele descobriu de R3 no local apropriado de sua tabela. 

Neste ponto, podemos ver o que acontece quando um pacote é encaminhado nessa rede. Suponha 
que um pacote destinado ao endereço IP 18.1.1.5 chegue da esquerda para o roteador R1. R1, neste 
caso, é chamado de roteador de borda por rótulo (LER — Label Edge Router); um LER realiza uma busca 
IP completa nos pacotes IP que chegam e depois aplica rótulos a eles como resultado da busca. Nesse 
caso, R1 veria que 18.1.1.5 corresponde ao prefixo 18.1.1 em sua tabela de encaminhamento e que essa 







18.1.1/24 


18.3.3/24 





Prefixo Int. Prefixo Int. 
18.1.1 0 18.1.1 1 
18.3.3 0 18.3.3 0 





FIGURA 4.18 Tabelas de roteamento na rede de exemplo. 
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18.1.1/24 





18.3.3/24 







Prefixo Int. Rótulo Prefixo Int. 
18.1.1 0 15| 181.1 1 
18.3.3 0 16| 18.3.3 0 





18.1.1/24 


18.3.3/24 
Rótulo 


Prefixo Int. remoto Rótulo Prefixo Int. 
18.1.1 015 15 18.1.1 1 


18.3.3 |O |16 16, 18.3.3 0 











18.1.1/24 


18.3.3/24 
Rótulo 


Prefixo Int.remoto Rótulo Prefixo | Int.remoto 
18.1.1 0 15 15| 181.1 1 24 


18.3.3 0 |16 16| 18.3.3 |0 


FIGURA 4.19 (a) R2 aloca rótulos e anuncia vínculos para R1. (b) R1 armazena os rótulos recebidos em uma tabela. (c) R3 anuncia outro 
vínculo e R2 armazena o rótulo recebido em uma tabela. 


entrada contém uma interface de saída e um valor de rótulo remoto. R1, portanto, conecta o rótulo 
remoto 15 ao pacote antes de enviá-lo. 

Quando o pacote chega em R2, este examina apenas o rótulo no pacote, e não o endereço IP A tabela 
de encaminhamento em R2 indica que os pacotes chegando com um valor de rótulo 15 devem ser 
enviados pela interface 1 e que eles devem transportar o valor de rótulo 24, conforme anunciado pelo 
roteador R3. R2, portanto, sobrescreve (troca) o rótulo e o encaminha para R3. 

O que foi realizado por toda essa aplicação e troca de rótulos? Observe que, quando R2 encaminhou o 
pacote neste exemplo, ele na realidade nunca precisou examinar o endereço IP Em vez disso, R2 examinou 
apenas o rótulo que chegou. Assim, substituímos a busca normal por endereços de destino do IP por uma 
busca de rótulo. Para entender por que isso é significativo, vale a pena lembrar que, embora os endereços 
IP sempre tenham o mesmo tamanho, os prefixos IP têm tamanhos variáveis, e o algoritmo de busca de 
endereço de destino do IP precisa encontrar a maior correspondência — o prefixo mais longo que corres- 
ponde aos bits de alta ordem no endereço IP do pacote sendo encaminhado. Em comparação, o mecanismo 
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de encaminhamento de rótulos que descrevemos é um algoritmo de correspondência exata. É possível 
implementar um algoritmo de correspondência exata muito simples, por exemplo, usando o rótulo como 
um índice de um vetor, onde cada elemento no vetor é uma linha na tabela de encaminhamento. 

Observe que, embora o algoritmo de encaminhamento tenha sido alterado, substituindo-se a corres- 
pondência mais longa pela correspondência exata, o algoritmo de roteamento pode ser qualquer algo- 
ritmo de roteamento IP padrão (por exemplo, OSPF). O caminho que um pacote seguirá nesse ambiente 
é exatamente o mesmo caminho que ele teria seguido se o MPSL não estivesse envolvido — o caminho 
escolhido pelos algoritmos de roteamento IP Tudo o que mudou é o algoritmo de encaminhamento. 

Um conceito fundamental importante do MPLS é ilustrado por este exemplo. Cada rótulo MPLS é 
associado a uma classe de equivalência de encaminhamento (FEC — Forwarding Equivalence Class) - um 
conjunto de pacotes que devem receber o mesmo tratamento de encaminhamento em um roteador em 
particular. Neste exemplo, cada prefixo na tabela de roteamento é uma FEC, ou seja, todos os pacotes 
que correspondem ao prefixo 18.1.1 — não importam quais sejam os bits de baixa ordem do endereço 
IP - são encaminhados pelo mesmo caminho. Assim, cada roteador pode alocar um rótulo que é mapea- 
do para 18.1.1, e qualquer pacote que contenha um endereço IP cujos bits de alta ordem correspondam 
a esse prefixo pode ser encaminhado usando esse rótulo. 

Conforme veremos nos exemplos seguintes, FECs são um conceito muito poderoso e flexível. FECs 
podem ser formadas usando quase qualquer tipo de critério; por exemplo, todos os pacotes corres- 
pondentes a um cliente em particular poderiam ser considerados como estando na mesma FEC. 

Retornando ao exemplo em questão, observamos que mudar o algoritmo de encaminhamento do 
encaminhamento IP normal para a comutação de rótulos tem uma consequência importante: os dispo- 
sitivos que anteriormente não sabiam como encaminhar pacotes IP podem ser usados para encaminhar 
tráfego IP em uma rede MPLS. A aplicação inicial mais notável desse resultado foi para switches ATM, 
que são capazes prover suporte a MPLS sem quaisquer mudanças em seu hardware de encaminhamento. 
Switches ATM têm suporte ao algoritmo de encaminhamento de comutação de rótulos descrito, e forne- 
cendo a esses switches protocolos de roteamento IP e um método para distribuir vínculos de rótulo, eles 
poderiam ser transformados em roteadores de comutação de rótulos (LSRs — Label Switching Routers) — 
dispositivos que executam protocolos de controle IP mas usam o algoritmo de encaminhamento por 
comutação de rótulos. Mais recentemente, a mesma ideia foi aplicada aos switches ópticos do tipo des- 
crito na Seção 3.1.2. 

Antes de considerarmos os benefícios em potencial de transformar um switch ATM em um LSR, 
devemos amarrar algumas pontas soltas. Dissemos que os rótulos são “adicionados” aos pacotes, mas 
onde exatamente eles são adicionados? A resposta depende do tipo de enlace em que os pacotes são 
transportados. Dois métodos comuns para transportar rótulos em pacotes aparecem na Figura 4.20. 
Quando os pacotes IP são transportados como quadros completos, como acontece na maioria dos 
tipos de enlace, incluindo Ethernet e PPP o rótulo é inserido como um “recheio” entre o cabeçalho da 
camada 2 e o cabeçalho IP (ou outro da camada 3), como mostra a parte inferior da figura. Porém, se um 
switch ATM tiver que funcionar como um LSR MPLS, então o rótulo precisa estar em um local onde o 
switch pode usá-lo, e isso significa que ele precisa estar no cabeçalho da célula ATM, exatamente onde 
normalmente se encontraria os campos de identificador de circuito virtual (VCI) e identificador de 
caminho virtual (VPN). 


GFC VPI VCI PTI | CLP | HEC DATA 


Lo] 


Rótulo 








(a) Cabeçalho de 
célula ATM 














(b) Cabeçalho de C 
“recheio” (para PPP, Cabeçalho PPP | Cabeçalho de rótulo (Cabeçalho da camada 3 
Ethernet etc.) 


FIGURA 4.20 (a) Rótulo em um pacote encapsulado com ATM; (b) rótulo sobre um pacote encapsulado em um quadro. 
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EM QUE CAMADA ESTÁ O MPLS? 


Tem havido muitos debates sobre onde o MPLS pertence nas arquiteturas de protocolo em camadas 
apresentadas na Seção 1.3. Como o cabeçalho MPLS normalmente é encontrado entre os cabeçalhos da 
camada 3 e da camada 2 de um pacote, ele às vezes é chamado de cabeçalho da camada 2.5. Algumas 
pessoas argumentam que, como os pacotes IP são encapsulados dentro de cabeçalhos MPLS, o MPLS deveria 
estar “abaixo” do IP tornando-o um protocolo da camada 2. Outros argumentam que, como os protocolos 

de controle para o MPLS são, em grande parte, os mesmos protocolos do IP - o MPLS usa protocolos de 
roteamento IP e endereçamento IP —, então o MPLS deveria estar na mesma camada do IP (ou seja, camada 
3). Conforme observamos na Seção 1.3, as arquiteturas em camadas são ferramentas úteis, mas nem sempre 
elas são capazes de descrever como exatidão o mundo real, e o MPLS é um bom exemplo de onde as visões 
estritamente de camadas podem ser difíceis de reconciliar com a realidade. 





Tendo agora idealizado um esquema pelo qual um switch ATM pode funcionar como um LSR, o que 
ganhamos? Uma coisa a observar é que poderíamos, agora, montar uma rede que use uma mistura de 
roteadores IP convencionais, roteadores de rótulo na borda rede e switches ATM funcionando como 
LSRs, e todos eles usariam os mesmos protocolos de roteamento. Para entender os benefícios do uso 
dos mesmos protocolos, considere a alternativa. Na Figura 4.21(a), vemos um conjunto de roteadores 
interconectados por circuitos virtuais sobre uma rede ATM, uma configuração chamada rede sobreposta, 
ou rede overlay. Em uma certa época, as redes desse tipo normalmente eram construídas porque os 
switches ATM disponíveis comercialmente admitiam um vazão total mais alta do que os roteadores. Hoje, 
redes como esta são menos comuns, pois os roteadores acompanharam e até mesmo ultrapassaram os 
switches ATM. Porém, essas redes ainda existem por causa da base instalada significativa de switches 
ATM em backbones da rede, o que por sua vez é, em parte, um resultado da capacidade do ATM de dar 
suporte a uma série de funcionalidades, como emulação de circuitos e serviços de circuito virtual. 

Em uma rede overlay, cada roteador potencialmente seria conectado a cada um dos outros rotea- 
dores por um circuito virtual, mas neste caso, por clareza, apenas mostramos os circuitos de R1 para 


FIGURA 4.21 (a) Roteadores conectam-se uns aos outros 
usando um overlay de circuitos virtuais. (b) Roteadores 
se conectam diretamente com LSRs. 
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todos os seus pares roteadores. R1 tem cinco vizinhos de roteamento e precisa trocar mensagens do 
protocolo de roteamento com todos eles — dizemos que R1 tem cinco adjacências de roteamento. Em 
comparação, na Figura 4.21 (b), os switches ATM foram substituídos por LSRs. Não há mais circuitos 
virtuais interconectando os roteadores. Assim, R1 tem apenas uma adjacência, com LSR1. Em redes 
grandes, executar MPLS nos switches leva a uma redução significativa no número de adjacências que 
cada roteador precisa manter e pode reduzir bastante a quantidade de trabalho que os roteadores 
precisam executar para manter uns aos outros informados das mudanças na topologia. 

Um segundo benefício de executar os mesmos protocolos de roteamento nos roteadores de borda e 
nos LSRs é que os roteadores de borda agora têm uma visão completa da topologia da rede. Isso significa 
que, se algum enlace ou nó falha dentro da rede, os roteadores de borda terão uma melhor chance de 
escolher adequadamente um caminho novo do que se os switches ATM redirecionassem os VCs afetados 
sem o conhecimento dos roteadores de borda. 

Observe que a etapa de “substituição” de switches ATM por LSRs é realmente alcançada mudando 
os protocolos que são executados nos switches, mas normalmente nenhuma mudança no hardware 
de encaminhamento é necessária; ou seja, um switch ATM normalmente pode ser convertido para um 
LSR MPLS fazendo a atualização apenas do seu software. Além disso, um LSR MPLS poderia continuar 
a dar suporte às funcionalidades padrão do ATM ao mesmo tempo em que executa os protocolos de 
controle MPLS, no que é conhecido como o modo “entrega noturna”. 

Mais recentemente, a ideia de executar os protocolos de controle IP nos dispositivos que são incapazes 
de encaminhar pacotes IP originalmente tinha sido estendida pelos switches ópticos e dispositivos STDM, 
como multiplexadores SONET. Isso é conhecido como MPLS Generalizado (GMPLS — Generalized MPLS). 
Parte da motivação para o GMPLS foi oferecer aos roteadores conhecimento topológico de uma rede óptica, 
assim como no caso do ATM. Ainda mais importante foi o fato de que não havia protocolos padrão para 
controlar dispositivos ópticos, de modo que o MPLS pareceu ser uma escolha natural para esta tarefa. 


4.3.2 Roteamento explícito 


Na Seção 3.1.3, introduzimos o conceito de roteamento na origem. O IP tem uma opção de roteamento 
na origem, mas isso não é muito usado por vários motivos, incluindo o fato de que somente um número 
limitado de saltos pode ser especificado e porque normalmente o processo é feito fora do “caminho 
rápido” na maioria dos roteadores. 

O MFLS oferece às redes IP um modo conveniente de acrescentar funcionalidades semelhantes ao 
roteamento na origem, embora a funcionalidade seja mais frequentemente chamada de roteamento 
explícito, em vez de roteamento na origem. Um motivo para a distinção é que normalmente não é a 
origem real do pacote que seleciona a rota. O mais comum é que seja um dos roteadores dentro da 
rede do provedor de serviços. A Figura 4.22 mostra um exemplo de como a capacidade de roteamento 
explícito do MPLS poderia ser aplicada. Esse tipo de rede normalmente é chamado de rede de peixe, 
devido à sua forma (os roteadores R1 e R2 formam a cauda; R7 é a cabeça). 





FIGURA 4.22 Uma rede exigindo roteamento explícito. 


“A expressão “entrega noturna” pode ser entendida como algo que acontece “de forma transparente”, sem que as entidades 
envolvidas se deem conta do ocorrido. (N.T.) 
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Suponha que o operador da rede na Figura 4.22 tenha determinado que qualquer tráfego fluindo de 
R1 para R7 deva seguir o caminho R1-R3-R6-R7 e que qualquer tráfego indo de R2 para R7 deva seguir 
o caminho R2-R3-R4-R5-R7. Um motivo para essa escolha seria fazer um bom uso da capacidade dis- 
ponível ao longo de dois caminhos distintos de R3 a R7. Podemos pensar no tráfego de R1 a R7 como 
constituindo de uma classe de equivalência de encaminhamento, e que o tráfego de R2 a R7 constitui 
uma segunda FEC. Encaminhar tráfego nessas duas classes ao longo de diferentes caminhos é algo difícil 
de se fazer com o roteamento IP normal, pois R3 normalmente não examina de onde o tráfego veio ao 
tomar suas decisões de encaminhamento. 

Como o MPLS utiliza a comutação de rótulos para encaminhar pacotes, é muito fácil conseguir o ro- 
teamento desejado se os roteadores forem habilitados com MPLS. Se R1 e R2 conectam rótulos distintos 
aos pacotes antes de enviá-los para R3 — identificando-os assim como estando em FECs diferentes —, 
então R3 pode encaminhar pacotes de R1 e R2 ao longo de diferentes caminhos. A pergunta que surge 
então é: como todos os roteadores na rede entram em acordo sobre quais rótulos usar e como encami- 
nhar pacotes com rótulos específicos? Certamente, não podemos usar os mesmos procedimentos des- 
critos na seção anterior para distribuir rótulos, pois esses procedimentos estabelecem rótulos que fazem 
com que os pacotes sigam os caminhos normais escolhidos pelo roteamento IP que é exatamente o que 
estamos tentando evitar. Ao invés disso, um novo mecanismo é necessário. Acontece que o protocolo 
utilizado para essa tarefa é o protocolo de reserva de recursos (RSVP — Resource Reservation Protocol). 
Falaremos mais sobre esse protocolo na Seção 6.5.2, mas por enquanto basta dizer que é possível enviar 
uma mensagem RSVP ao longo de um caminho especificado explicitamente (por exemplo, R1-R3-R6-R7) 
e usá-la para configurar entradas em tabelas de encaminhamento de rótulos por todo esse caminho. 
Isso é muito semelhante ao processo de estabelecer um circuito virtual descrito na Seção 3.3. 

Uma das aplicações do roteamento explícito é a engenharia de tráfego, que se refere à tarefa de 
garantir a disponibilidade de recursos suficientes em uma rede para atender as demandas impostas 
sobre ela. Uma parte importante da engenharia de tráfego é controlar em quais caminhos o tráfego flui. 
O roteamento explícito também pode ajudar a tornar as redes mais flexíveis em caso de falha, usando 
uma capacidade chamada redirecionamento rápido. Por exemplo, é possível pré-calcular um caminho 
do roteador A para o roteador B que evite explicitamente certo enlace L. No evento de o enlace L falhar, 
o roteador A poderia enviar todo o tráfego destinado a B pelo caminho pré-calculado. A combinação de 
pré-cálculo do caminho reserva e o roteamento explícito dos pacotes ao longo do caminho significa que 
Anão precisa esperar que os pacotes do protocolo de roteamento consigam atravessar a rede ou que os 
algoritmos de roteamento sejam executados por vários outros nós na rede. Em certas circunstâncias, 
isso pode reduzir significativamente o tempo gasto para redirecionar pacotes de forma a contornar um 
ponto de falha. 

Um último ponto a observar sobre o roteamento explícito é que as rotas explícitas não precisam ser 
calculadas por um operador da rede, como no exemplo anterior. Os roteadores podem usar diversos 
algoritmos para calcular rotas explícitas automaticamente. O mais comum deles é o caminho restrito 
mais curto primeiro (CSPF — Constrained Shortest Path First), que é como os algoritmos por estado do 
enlace descritos na Seção 3.3.3, mas também leva em conta diversas restrições. Por exemplo, se for 
necessário encontrar um caminho de R1 até R7 que possa transportar uma carga oferecida de 100 Mbps, 
poderíamos dizer que a restrição é que cada enlace deve ter pelo menos 100 Mbps de capacidade dis- 
ponível. O CSPF resolve esse tipo de problema. Outros detalhes sobre CSPF e as aplicações do roteamento 
explícito são fornecidos na seção de Leitura Adicional. 


4.3.3 Redes privadas virtuais e túneis 


Primeiro, falamos sobre as redes privadas virtuais (VPNs) na Seção 3.2.9, e observamos que um modo de 
criá-las é usando túneis. Acontece que o MPLS pode ser imaginado como um modo de montar túneis, 
e isso o torna adequado para montar VPNs de vários tipos. 

A forma de VPN MPLS mais simples de entender é uma VPN da camada 2. Nesse tipo de VPN, o MPLS 
é usado para tunelar dados da camada 2 (como quadros Ethernet ou células ATM) por uma rede de 
roteadores habilitados para MPLS. Lembre-se, da Seção 3.2.9, que um motivo para os túneis é fornecer 
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FIGURA 4.23 Um circuito ATM é emulado por um túnel. 


algum tipo de serviço de rede (como multicast) que não é suportado por alguns roteadores na rede. A 
mesma lógica se aplica aqui: roteadores IP não são switches ATM, de modo que você não pode oferecer 
um serviço de circuito virtual ATM por uma rede de roteadores convencionais. Porém, se você tivesse 
um par de roteadores interconectados por um túnel, eles poderiam enviar células ATM pelo túnel e 
emular um circuito ATM. O termo para essa técnica dentro da IETF é pseudowire emulation (algo como 
“emulação de pseudofio”). A Figura 4.23 ilustra a ideia. 

Já vimos como os túneis IP são montados: o roteador na entrada do túnel encapsula os dados a serem 
enviados por túnel em um cabeçalho IP (o cabeçalho do túnel), que representa o endereço do roteador 
na extremidade de saída do túnel e envia os dados como qualquer outro pacote IP. O roteador receptor 
recebe o pacote com seu próprio endereço no cabeçalho, retira o cabeçalho do túnel, e verifica os dados 
que foram enviados pelo túnel, que são então processados. O que exatamente ele faz com os dados 
depende do que eles são. Por exemplo, se fosse outro pacote IP ele seria então encaminhado como um 
pacote IP normal. Porém, ele não precisa ser um pacote IP contanto que o roteador receptor saiba o que 
fazer com pacotes não IP Retornaremos à questão de como lidar com dados não IP mais adiante. 

Um túnel MPLS não é muito diferente de um túnel IP exceto que o cabeçalho do túnel consiste em 
um cabeçalho MPLS em vez de um cabeçalho IP Examinando nosso primeiro exemplo, na Figura 4.19, 
vimos que o roteador R1 adicionou um rótulo (15) a cada pacote que ele enviou para o prefixo 18.1.1. 
Esse pacote, então, seguiria o caminho R1-R2-R3, com cada roteador no caminho examinando apenas 
o rótulo MPLS. Assim, observamos que não houve o requisito de que R1 só envie pacotes IP ao longo 
desse caminho — quaisquer dados poderiam ser encapsulados no cabeçalho MPLS e eles seguiriam o 
mesmo caminho, pois os roteadores intermediários nunca examinam algo além do cabeçalho MPLS. 
Em relação a isso, um cabeçalho MPLS é exatamente como um cabeçalho de túnel IP? O único problema 
com o envio de tráfego não IP por um túnel, MPLS ou outro, é o que fazer com o tráfego não IP quando 
ele alcança o final do túnel. A solução geral é transportar algum tipo de identificador de demultiplexação 
no payload do túnel, que diga ao roteador no final do túnel o que fazer. Acontece que um rótulo MPLS 
é uma escolha perfeita para esse identificador. Um exemplo esclarecerá isso. 

Vamos supor que queiramos enviar células ATM por túnel de um roteador para outro por uma rede 
de roteadores habilitados com MPLS, como na Figura 4.23. Além disso, consideramos que o objetivo 
é emular um circuito virtual ATM, ou seja, as células chegam à entrada, ou cabeça, do túnel em certa 
porta de entrada com certo VCI e deve sair da outra extremidade do túnel, a cauda, em certa porta de 
saída e com um VCI potencialmente diferente. Isso pode ser feito configurando os roteadores da cabeça 
e da cauda da seguinte forma: 


e Oroteador na cabeça precisa ser configurado com a porta de chegada, o VCI de chegada, o rótulo 
de demultiplexação para esse circuito emulado e o endereço do túnel e roteador. 

e Oroteador da cauda precisa ser configurado com a porta de saída, o VCI de saída e o rótulo de 
demultiplexação. 


Quando os roteadores tiverem essa informação, podemos ver como uma célula ATM seria encami- 


nhada. A Figura 4.24 ilustra as etapas. 


“Observe, porém, que um cabeçalho MPLS tem apenas 4 bytes, em comparação com os 20 do cabeçalho IP implicando em 
uma economia de largura de banda quando o MPLS é usado. 
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1. Células ATM chegando 6. Células ATM enviadas 









2. Rótulo demux acrescentado DL |101 
[DL] TL | DL|101 5. Rótulo demux examinado 





4. Pacote encaminhado à cauda 
3. Rótulo de túnel acrescentado 


TL | DL[|101 


FIGURA 4.24 Encaminhamento de células ATM por um túnel. 





1. Uma célula ATM chega à porta de entrada designada com o valor de VCI apropriado (101 neste 
exemplo). 

2. O roteador da cabeça adiciona o rótulo de demultiplexação que identifica o circuito emulado. 

3. O roteador na cabeça então adiciona um segundo rótulo, que é o rótulo do túnel que levará o 
pacote até o roteador de cauda. Esse rótulo é determinado usando mecanismos semelhantes 
àqueles descritos na Seção 4.3.1. 

4. Os roteadores entre a cabeça e a cauda encaminham o pacote usando apenas o rótulo do túnel. 

5. O roteador da cauda remove o rótulo do túnel, encontra o rótulo de demultiplexação e reconhece 
o circuito emulado. 

6. O roteador de cauda troca o VCI ATM para o valor correto (202, neste caso) e o envia pela porta correta. 


Um item neste exemplo que poderia ser surpreendente é que o pacote tem dois rótulos conectados 
a ele. Este é um dos recursos interessantes do MPLS — rótulos podem ser empilhados em um pacote até 
qualquer profundidade. Isso fornece algumas funcionalidades úteis para obter maior escalabilidade. 
Neste exemplo, isso permite que um único túnel transporte um número potencialmente alto de circuitos 
emulados. 

A mesma técnica descrita aqui pode ser aplicada para emular muitos outros serviços da camada 2, 
incluindo Frame Relay e Ethernet. Vale a pena observar que funcionalidades praticamente idênticas 
podem ser fornecidas usando túneis IP; a vantagem principal do MPLS aqui é o cabeçalho de túnel 
mais curto. 

Antes que o MPLS fosse usado para enviar serviços da camada 2 por túnel, ele também estava sendo 
usado para dar suporte às VPNs da camada 3. Não entraremos nos detalhes das VPNs da camada 3, que 
são muito complexas (veja na seção Leitura Adicional algumas boas fontes de mais informações), mas 
observamos que elas representam um dos usos mais populares do MPLS hoje. As VPNs da camada 3 
também usam pilhas de rótulos MPLS para tunelar pacotes por uma rede IP Porém, os pacotes que são 
tunelados são, por si sós, pacotes IP — daí o nome VPNs da camada 3. Em uma VPN da camada 3, um 
único provedor de serviços opera uma rede de roteadores habilitados com MPLS e oferece um serviço 
de rede IP “virtualmente privada” para qualquer quantidade de clientes distintos. Ou seja, cada cliente 
do provedor tem alguma quantidade de locais, e o provedor de serviços cria a ilusão para cada cliente de 
que não existem outros clientes na rede. O cliente vê uma rede IP interconectando seus próprios locais 
e nenhum outro local. Isso significa que cada cliente é isolado de todos os outros clientes em termos 
de roteamento e endereçamento. O cliente A não pode enviar pacotes diretamente para o cliente B, e 
vice-versa.º O cliente A pode ainda usar os endereços IP que também foram usados pelo cliente B. A ideia 
básica é ilustrada na Figura 4.25. Assim como nas VPNs da camada 2, o MPLS é usado para enviar pacotes 
por um túnel de um local para outro; porém, a configuração dos túneis é realizada automaticamente 
usando o BGP de uma forma bastante elaborada, algo que está além do escopo deste livro. 


60 cliente A, na realidade, normalmente pode enviar dados ao cliente B de alguma forma restrita. Mais provavelmente, os 
clientes A e B têm alguma conexão com a Internet global, e assim provavelmente é possível que o cliente A envie mensagens de 
e-mail, por exemplo, ao servidor de correio dentro da rede de B. A “privacidade” oferecida por uma VPN impede que o cliente A 
tenha acesso irrestrito a todas as máquinas e sub-redes dentro da rede do cliente B. 
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FIGURA 4.25 Exemplo de uma VPN da camada 3. Os clientes A e B obtêm um serviço IP virtualmente privado de um único provedor. 


Resumindo, o MPLS é uma ferramenta bastante versátil, que tem sido aplicada a uma grande gama 
de problemas de rede diferentes. Ele combina o mecanismo de encaminhamento com substituição de 
rótulos, que normalmente é associado a redes de circuitos virtuais, com os protocolos de roteamento 
e controle das redes de datagramas IP produzindo uma classe de rede que está em algum ponto entre 
os dois extremos convencionais. Isso estende as capacidades das redes IP para permitir, entre outras 
coisas, o controle mais preciso do roteamento e o suporte para uma série de serviços de VPN. 


ONDE ESTÃO ELES AGORA? 


IMPLANTAÇÃO DO MPLS 

Originalmente concebido como uma tecnologia que operaria dentro da rede de provedores de serviços 
individuais, o MPLS continua oculto da maioria dos usuários da Internet de hoje, sejam eles consumidores 
ou acadêmicos. Porém, agora ele é suficientemente popular entre os provedores de serviços, tanto que se 
tornou quase obrigatório para os fabricantes de roteadores de alto nível incluírem capacidades de MPLS em 
seus produtos. O sucesso generalizado do MPLS é um segredo relativamente bem guardado, pelo menos para 
alunos e pesquisadores voltados à Internet pública. 

Duas aplicações principais do MPLS são responsáveis pela maior parte de sua implantação. A aplicação 
de VPN da camada, descrita nesta seção, é a principal aplicação para o MPLS. Quase todo provedor de 
serviços do mundo agora oferece um serviço de VPN da camada 3 baseado em MPLS. Esse, normalmente, 

é executado em roteadores que estão basicamente separados da Internet, pois o uso principal das VPNs da 
camada 3 é oferecer serviço de IP privado às empresas, e não fornecer conectividade à Internet global. Alguns 
provedores, porém, executam seu serviço de Internet e serviço de VPN sobre um backbone comum. 

O segundo uso popular do MPLS é o roteamento explícito, seja para engenharia de tráfego, rerroteamento 
rápido, ou ambos. Diferente do serviço de VPN da camada 3, que é explicitamente comercializado para 
clientes finais, o roteamento explícito é uma capacidade interna que os provedores usam para melhorar a 
confiabilidade de suas redes ou reduzir seus custos. Os provedores normalmente não publicam detalhes de 
seus projetos de rede interna, tornando mais difícil determinar quantos provedores realmente usam essa 
tecnologia. É óbvio que os recursos de roteamento explícito do MPLS são usados por menos provedores 
do que os recursos de VPN, mas apesar disso existe evidência de uso significativo, especialmente quando a 
largura de banda é cara ou quando existe um forte desejo de manter dois níveis de congestionamento (por 
exemplo, para dar suporte a serviços em tempo real). 
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4.4 Roteamento entre dispositivos móveis A 


WLAN móvel 

Provavelmente não deverá ser grande surpresa descobrir que os dispositivos móveis apresentam alguns 
desafios à arquitetura da Internet. A Internet foi projetada em uma época em que os computadores 
eram dispositivos grandes e imóveis e, embora os projetistas da Internet provavelmente tivessem 
alguma noção de que os dispositivos móveis pudessem aparecer no futuro, é razoável considerar que 
não foi uma alta prioridade acomodá-los. Hoje, é claro, os computadores móveis estão em toda a parte, 
principalmente na forma de notebooks e telefones móveis habilitados para IP e cada vez mais em outros 
formatos, como nos sensores. Nesta seção, veremos alguns dos desafios impostos pelo surgimento de 
dispositivos móveis e algumas das técnicas atuais para acomodá-los. 


4.4.1 Desafios para a rede móvel 


Amaioria dos leitores deste livro provavelmente já terá usado um dispositivo móvel em rede em algum ponto, 
e para muitos de nós os dispositivos móveis tornaram-se a norma. Assim, pode-se razoavelmente pensar que 
a rede móvel é um problema resolvido. Certamente, é muito fácil descobrir hoje um ponto de acesso sem 
fios, conectar-se à Internet usando 802.11 ou algum outro protocolo de rede sem fios e obter um serviço de 
Internet muito bom. Uma tecnologia de suporte chave que tornou o ponto de acesso viável é o DHCP (ver 
detalhes na Seção 3.2.7). Você pode entrar em uma lanchonete, abrir seu notebook, obter um endereço IP 
para o seu notebook e fazer com que ele fale com um roteador padrão e um servidor de DNS (Domain Name 
System) (ver Seção 9.3.1) e, para uma grande classe de aplicações, você já terá tudo o que precisa. 

Porém, se olharmos um pouco mais atentamente, ficará claro que, para alguns cenários de aplicação, 
apenas obter um novo endereço IP toda vez que você se move — que é o que DHCP faz para você - nem 
sempre é suficiente. Suponha que você esteja usando seu laptop ou smartphone para uma chamada 
telefônica usando Voz sobre IP e enquanto fala ao telefone, você se afasta de um ponto de acesso para 
outro, ou mesmo passa de 802.11 para 3G sem fio com forma de conexão com a Internet. 

Logicamente, quando você passa de uma rede de acesso para outra, precisa obter um novo endereço 
IP - aquele que corresponde à nova rede. Porém, o computador ou telefone na outra ponta da sua conversa 
não sabe imediatamente aonde você se moveu ou qual é o seu novo endereço IP Consequentemente, na 
ausência de algum outro mecanismo, os pacotes continuariam a ser enviados para o endereço onde você 
estava, e não onde você está agora. Esse problema é ilustrado na Figura 4.26; à medida que o nó móvel 
passa da rede 802.11 na Figura 4.26(a) para a rede de celular na Figura 4.26(b), de alguma forma os pacotes 
do nó correspondente precisam seguir seu caminho até a nova rede e em seguida para o nó móvel. 

Existem muitas formas diferentes de enfrentar o problema descrito, e veremos alguns deles a seguir. 
Supondo que haja alguma maneira de redirecionar pacotes de modo que eles cheguem ao seu novo 
endereço, em vez do seu endereço antigo, os próximos problemas imediatamente evidentes estão 
relacionados à segurança. Por exemplo, se houver um mecanismo pelo qual eu possa dizer “meu novo 
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Å “U (d FIGURA 4.26 Encaminhando pacotes de um nó 


correspondente para um nó móvel. 
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endereço IP é X”, como eu impeço que algum atacante faça tal declaração sem a minha permissão, per- 
mitindo assim que ele receba meus pacotes ou redirecione meus pacotes para algum terceiro indesejado? 
Assim, vemos que a segurança e a mobilidade estão bastante relacionadas. 

Um problema que a discussão anterior destaca é o fato de que os endereços IP realmente têm duas 
tarefas. Eles são usados como um identificador de um terminal, e também são usados para localizar 
o terminal. Pense no identificador como um nome de longa duração para o terminal, e o localizador 
como alguma informação mais temporária sobre como rotear pacotes para o terminal. Contanto que os 
dispositivos não se movam, ou que não se movam frequentemente, o uso de um único endereço para 
as duas tarefas parece ser bastante razoável. Mas quando os dispositivos começam a se mover, você 
gostaria de ter um identificador que não mude enquanto você se move — isso, às vezes, é chamado de 
Identificador de Terminal ou Identificador de Host — e um localizador separado. Essa ideia de separar 
os localizadores dos identificadores já existe há muito tempo, e a maioria das técnicas para lidar com a 
mobilidade, descritas a seguir, fornece essa separação de alguma forma. 

A suposição de que os endereços IP não mudam aparece em muitos lugares diferentes. Por exemplo, 
conforme veremos no próximo capítulo, os protocolos de transporte como TCP historicamente fizeram 
suposições sobre o endereço IP permanecendo constante durante toda uma conexão, de modo que os 
protocolos de transporte operando em um mundo móvel exigem alguma reavaliação dessa suposição. 

Embora estejamos todos acostumados com terminais que se movem, vale a pena observar que os 
roteadores também podem se mover. Isso certamente é menos comum hoje do que a mobilidade do 
terminal, mas existem muitos ambientes onde um roteador móvel poderia fazer sentido. Um exemplo 
poderia ser por uma equipe de resposta a emergências, tentando implantar uma rede após algum de- 
sastre natural ter atingido toda a infraestrutura fixa. Existem outras considerações quando todos os nós 
em uma rede são móveis, e não apenas os terminais, um assunto que discutiremos na Seção 4.4.2. 

Assim como em muitas tecnologias, o suporte a mobilidade levanta questões de implantação in- 
cremental. Dado que, durante suas primeiras décadas, a Internet consistia totalmente em nós que não 
se moviam, é razoável supor que haverá muitos roteadores e hosts por um futuro previsível que fazem 
essa suposição. Daí as soluções de mobilidade precisarem lidar com a implantação incremental. Por 
outro lado, o IP versão 6 foi capaz de fazer com que a mobilidade se tornasse parte do seu projeto desde 
o início, o que lhe oferece algumas vantagens. 

Antes de começarmos a ver algumas das técnicas para dar suporte a dispositivos móveis, vamos es- 
clarecer alguns pontos. É comum descobrir que as pessoas confundem redes sem fios com mobilidade. 
Afinal, a mobilidade e as redes sem fios normalmente são encontradas juntas por motivos óbvios. Mas 
a comunicação sem fios trata-se, na realidade, de levar os dados de A para B sem um fio, conforme dis- 
cutido com algum detalhe no Capítulo 2, enquanto a mobilidade refere-se a lidar com o que acontece 
quando um nó se movimenta enquanto está se comunicando. Certamente, muitos nós que usam canais 
de comunicação sem fios não são móveis, e, às vezes, os nós móveis usarão comunicação com fios 
(embora isso seja menos comum). 

Finalmente, neste capítulo estamos interessados principalmente no que poderíamos chamar 
de mobilidade da camada de rede. Ou seja, estamos interessados em como lidar com nós que se movem de 
uma rede para outra. Como vimos na Seção 2.7, passar de um ponto de acesso para outro na mesma rede 
802.11 pode ser tratado por mecanismos específicos do 802.11, e as redes de telefonia celular também 
possuem maneiras de lidar com a mobilidade, é claro, mas em grandes sistemas heterogêneos, como a 
Internet, precisamos dar suporte à mobilidade de forma mais ampla entre as redes. 


4.4.2 Roteamento para hosts móveis (IP móvel) 


O IP móvel é o principal mecanismo na arquitetura da Internet de hoje para enfrentar o problema de 
roteamento de pacotes para hosts móveis. Ele introduz algumas funcionalidades novas, mas não exige 
qualquer mudança nos hosts móveis ou na maioria dos roteadores — enfrentando, assim, a questão da 
implantação incremental, levantada anteriormente. 

O host móvel é considerado como tendo um endereço IP permanente, chamado endereço nativo 
(home address), que tem um prefixo de rede igual ao de sua rede nativa (home network). Esse é o endereço 
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FIGURA 4.27 Host móvel e agentes de mobilidade. 
Host emissor 
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que será usado por outros hosts quando eles enviarem pacotes inicialmente para o host móvel; como ele 
não muda, pode ser usado por aplicações de longa duração enquanto o host se move. Podemos pensar 
nisso como um identificador de longa duração para o host. 

Quando o host se move para uma nova rede externa (foreign network), longe de sua rede nativa, ele 
normalmente adquire um novo endereço nessa rede, usando algum mecanismo como o DHCP” Esse 
endereço mudará toda vez que o host se mover para uma nova rede, de modo que podemos pensar nele 
como sendo o localizador para o host, mas é importante observar que o host não perde seu endereço 
nativo permanente quando adquire um novo endereço na rede externa. Esse endereço nativo é crítico 
para a sua capacidade de sustentar as comunicações enquanto se move, como veremos em seguida. 

Enquanto a maior parte dos roteadores permanece inalterada, o suporte a mobilidade exige alguma 
funcionalidade nova pelo menos em um roteador, conhecido como agente nativo (home agent) do nó 
móvel. Esse roteador fica localizado na rede nativo do host móvel. Em alguns casos, um segundo rotea- 
dor, com funcionalidade avançada, o agente externo (foreign agent), também é exigido. Esse roteador 
fica localizado em uma rede à qual o nó móvel se conecta quando está longe de sua rede nativa. Vamos 
considerar primeiro a operação do IP móvel quando um agente externo é usado. Uma rede de exemplo 
com agentes nativos e externos aparece na Figura 4.27. 

Os agentes nativo e externo anunciam periodicamente sua presença nas redes às quais estão conec- 
tados usando mensagens de anúncio de agente. Um host móvel também pode solicitar um anúncio 
quando se conecta a uma nova rede. O anúncio enviado pelo agente nativo permite que um host móvel 
descubra o endereço de seu agente nativo antes de sair de sua rede nativa. Quando o host móvel se 
conecta a uma rede externa, ele escuta um anúncio de um agente externo e registra-se junto ao agente, 
fornecendo o endereço do seu agente nativo. O agente externo, então, entra em contato com o agente 
nativo, fornecendo um endereço de tratamento (care-of address).º Esse normalmente é o endereço IP 
do agente externo. 

Neste ponto, podemos ver que qualquer host que tente enviar um pacote para o host móvel o enviará 
com um endereço de destino igual ao endereço local desse nó. O encaminhamento IP normal fará que 
esse pacote chegue à rede local do nó móvel em que o agente nativo está situado. Assim, podemos dividir 
o problema de entregar o pacote ao nó móvel em três partes: 


1. Como o agente nativo intercepta um pacote que é destinado ao nó móvel? 
2. Como o agente nativo entrega o pacote ao agente externo? 
3. Como o agente externo entrega o pacote ao nó móvel? 


O primeiro problema pode parecer fácil se você examinar a Figura 4.27, em que o agente nativo, 
claramente, é o único caminho entre o host emissor e a rede nativa e, portanto, deve receber pacotes 
que são destinados ao nó móvel. Mas, e se o nó emissor (correspondente) estivesse na rede 18, ou e se 
houvesse outro roteador conectado à rede 18 que tentasse entregar o pacote sem passar pelo agente 
nativo? Para resolver esse problema, o agente nativo de fato personifica o nó móvel, usando uma técnica 


"Como o DHCP foi desenvolvido, mais ou menos, na mesma época do IP móvel (Mobile IP), os padrões de IP móvel 
originais não exigiam DHCP mas hoje o DHCP está presente em toda a parte. 

80 nome care-of address tem sua origem no sistema de correios tradicional, no qual a expressão care-of (“aos cuidados de”) 
é usada para indicar o nome de um destinatário específico da carta (possivelmente diferente do proprietário da residência 
onde a carta é entregue). (N.T.) 
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chamada proxy ARP. Este mecanismo funciona exatamente como o protocolo de resolução de endereços 
(ARP — Address Resolution Protocol), conforme descrevemos na Seção 3.2.6, exceto que o agente nativo 
insere o endereço IP do nó móvel, em vez do seu próprio, nas mensagens ARP. Ele usa seu próprio 
endereço de hardware, de modo que todos os nós na mesma rede aprendem a associar o endereço de 
hardware do agente nativo com o endereço IP do nó móvel. Um aspecto sutil desse processo é o fato 
de a informação do ARP poder ser mantida em cache nos outros nós da rede. Para garantir que esses 
caches sejam invalidados a tempo, o agente nativo emite uma mensagem ARP assim que o nó móvel 
se registra com um agente externo. Como a mensagem ARP não é uma resposta a uma solicitação ARP 
normal, ela é chamada de ARP gratuito. 

O segundo problema é a entrega do pacote interceptado ao agente externo. Aqui, usamos a técnica 
de tunelamento descrita na Seção 3.2.9. O agente nativo simplesmente encapsula o pacote dentro de 
um cabeçalho IP que é destinado ao agente externo e o transmite à inter-rede. Todos os roteadores 
intermediários simplesmente veem um pacote IP destinado ao endereço IP do agente externo. Outra 
forma de ver isso é que um túnel IP é estabelecido entre o agente nativo e o agente externo, e o agente 
nativo simplesmente coloca nesse túnel os pacotes destinados ao nó móvel. 

Quando um pacote finalmente chega ao agente externo, ele retira o cabeçalho IP extra e encontra 
dentro dele um pacote IP destinado ao endereço nativo do nó móvel. Claramente, o agente externo 
não pode tratar isso como qualquer outro pacote IP pois isso faria com que ele fosse enviado de volta 
à rede nativa. Ao invés disso, ele precisa reconhecer o endereço como o de um nó móvel registrado. 
Em seguida, ele entrega o pacote ao endereço de hardware do nó móvel (por exemplo, seu endereço 
Ethernet), que foi descoberto como parte do processo de registro. 

Uma observação que pode ser feita sobre esses procedimentos é que é possível que o agente externo e 
o nó móvel estejam no mesmo dispositivo; ou seja, um nó móvel pode realizar a função do agente externo 
ele mesmo. Porém, para que isso funcione, o nó móvel precisa ser capaz de adquirir dinamicamente um 
endereço IP que está localizado no espaço de endereços da rede externa (por exemplo, usando DHCP). 
Esse endereço, então, será usado como endereço de tratamento. Em nosso exemplo, esse endereço teria 
um número de rede 12. Essa abordagem tem a característica desejável de permitir que nós móveis se 
conectem às redes que não têm agentes externos; assim, a mobilidade pode ser alcançada somente 
com o acréscimo de um agente nativo e algum software novo no nó móvel (supondo que o DHCP seja 
usado na rede externa). 

E o tráfego no outro sentido (ou seja, do nó móvel para o nó fixo)? Acontece que isso é muito mais 
fácil. O nó móvel simplesmente coloca o endereço IP do nó fixo no campo de destino dos seus pacotes 
IP enquanto coloca seu endereço permanente no campo de origem, e os pacotes são encaminhados 
para o nó fixo usando meios normais. Naturalmente, se os dois nós em uma conversa forem móveis, 
então os procedimentos descritos anteriormente são usados em cada sentido. 


Otimização de rota no IP móvel 

Existe uma desvantagem significativa na técnica apresentada: a rota do nó correspondente até o nó 
móvel pode ser significativamente mais longa do que o ideal. Um dos exemplos mais extremos é quando 
um nó móvel e o nó correspondente estão na mesma rede, mas a rede nativa para o nó móvel está na 
outra extremidade da Internet. O nó correspondente emissor endereça todos os pacotes à rede nativa; 
eles atravessam a Internet para alcançar o agente nativo, que em seguida os envia de volta por túnel 
pela Internet para alcançar o agente externo. Claramente, seria bom se o nó correspondente pudesse 
descobrir que o nó móvel está na realidade na mesma rede e entregasse o pacote diretamente. No 
caso mais geral, o objetivo é entregar pacotes o mais diretamente possível do nó correspondente ao 
nó móvel sem passar por um agente nativo. Isso, às vezes, é conhecido como problema do roteamento 
triangular, pois o caminho do correspondente ao nó móvel por meio do agente nativo usa dois lados 
de um triângulo, em vez do terceiro lado que é o caminho direto. 

Aideia básica por trás da solução para o roteamento triangular é permitir que o nó correspondente 
saiba o endereço de tratamento do nó móvel. O nó correspondente pode, então, criar seu próprio túnel 
para o agente externo. Isso é tratado como uma otimização do processo recém descrito. Se o emissor 
tiver sido equipado com o software necessário para descobrir o endereço de tratamento e criar seu 
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próprio túnel, então a rota pode ser otimizada; se não, os pacotes simplesmente seguem a rota mais 
longa do que o ideal. 

Quando um agente nativo vê um pacote destinado para um dos nós móveis aos quais eles está dando 
suporte ele pode deduzir que o emissor não está usando a rota ideal. Portanto, ele envia uma mensagem 
de “atualização de vínculo” de volta à origem, além de encaminhar o pacote de dados ao agente externo. 
A origem, se for capaz, utiliza essa atualização de vínculo para criar uma entrada em um cache de vínculo, 
que consiste em uma lista de mapeamentos entre endereços de nó móvel e endereços de tratamento. Da 
próxima vez que essa origem tiver um pacote de dados para enviar para esse nó móvel, ela encontrará 
o vínculo no cache e poderá enviar o pacote por túnel diretamente ao agente externo. 

Existe um problema óbvio com esse esquema: o cache de vínculo pode ficar desatualizado se o host 
móvel migrar para uma nova rede. Se uma entrada de cache desatualizada for usada, o agente estrangeiro 
receberá pacotes por túnel para um nó móvel que não está mais registrado nessa rede. Nesse caso, ele 
envia uma mensagem de advertência de vínculo de volta ao emissor, a fim de lhe pedir que pare de usar 
essa entrada em cache. Porém, esse esquema só funciona no caso em que o agente estrangeiro não é 
o próprio nó móvel. Por esse motivo, as entradas em cache precisam ser excluídas após algum período 
de tempo; o tempo exato é especificado na mensagem de atualização de vínculo. 

Conforme observamos, o roteamento móvel oferece alguns desafios de segurança interessantes, 
que são mais claros agora que vimos como o IP móvel funciona. Por exemplo, um atacante que queira 
interceptar os pacotes destinados a algum outro nó em uma inter-rede poderia entrar em contato com 
o agente nativo para esse nó e se anunciar como o novo agente externo para o nó. Assim, fica claro que 
alguns mecanismos de autenticação são necessários. Discutiremos esses mecanismos no Capítulo 8. 


Mobilidade no IPv6 

Existem algumas diferenças significativas entre o suporte à mobilidade no IPv4 e no IPv6. Ainda mais 
importante, foi possível criar suporte para mobilidade nos padrões para IPv6 praticamente desde o 
início, aliviando assim uma série de problemas relativo à sua implantação incremental. (Pode ser mais 
correto dizer que o IPv6 é um grande problema de implantação incremental que, se resolvido, oferecerá 
suporte para mobilidade como parte do pacote.) 

Como os hosts habilitados para IPv6 podem adquirir um endereço sempre que estiverem conectados 
a uma rede externa (usando vários mecanismos definidos como parte das especificações v6 básicas), 
o IPv6 móvel dispensa o uso do agente externo e inclui em cada host os mecanismos necessários para 
que ele possa atuar como um agente externo. 

Um outro aspecto interessante do IPv6 que entra em cena com o IP móvel é a inclusão de um con- 
junto flexível de cabeçalhos de extensão, conforme descrito na Seção 4.1.3. Isso é usado no cenário de 
roteamento otimizado descrito anteriormente. Em vez de fazer o tunelamento de um pacote para o nó 
móvel usando seu endereço de tratamento, um nó IPv6 pode enviar um pacote IP para o endereço de 
tratamento com o endereço nativo contido em um cabeçalho de roteamento. Esse cabeçalho é ignorado 
por todos os nós intermediários, mas permite que o nó móvel trate o pacote como se fosse enviado 
ao endereço nativo, permitindo-lhe, assim, que continue fornecendo aos protocolos da camada mais 
alta a ilusão de que seu endereço IP é fixo. Usar um cabeçalho de extensão em vez de um túnel é mais 
eficiente do ponto de vista do consumo de largura de banda e processamento. 

Por fim, observamos que muitas questões abertas permanecem na rede móvel. O gerenciamento 
do consumo de energia dos dispositivos móveis é cada vez mais importante, de modo que dispositivos 
menores, com alimentação de bateria limitada, podem ser criados. Há também o problema das redes 
móveis ad hoc — permitindo que um grupo de nós móveis forme uma rede na ausência de quaisquer 
nós fixos — que têm alguns desafios especiais (veja a nota em destaque). Uma classe de redes móveis 
particularmente desafiadora, as redes de sensores, foi mencionada anteriormente. Os sensores nor- 
malmente são pequenos, baratos e alimentados por bateria, significando que as questões de muito 
pouco consumo de energia e capacidade de processamento limitada também devem ser consideradas. 
Ademais, como as comunicações sem fios e a mobilidade normalmente andam lado a lado, os avanços 
contínuos em tecnologias sem fio continuam produzindo novos desafios e oportunidades para as 
redes móveis. 
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REDES MÓVEIS AD HOC 


Na maior parte desta seção, supomos que apenas os nós finais (hosts) são móveis. Essa certamente é uma boa 
descrição do modo como a maioria de nós lida com as redes hoje. Nossos notebooks e telefones se movem 

e se conectam à infraestrutura fixa, como torres de celular e pontos de acesso 802.11, que se conectam 

por enlaces fixos ao backbone da Internet. Porém, muitos roteadores modernos também são pequenos o 
suficiente para serem móveis, e existem ambientes onde os roteadores móveis seriam úteis, como na criação 
de redes entre veículos móveis. Como os protocolos de roteamento são dinâmicos, você pode imaginar 

que o roteador móvel ocasional não seria um problema, e isso é mais ou menos correto. Porém, e se todos 

ou a maioria dos nós em uma rede fossem móveis? Levando ao extremo lógico, você poderia ter uma rede 
sem qualquer infraestrutura fixa - apenas uma coleção de nós móveis, alguns ou todos funcionando como 
roteadores. Os protocolos de roteamento padrão funcionariam nesse tipo de ambiente? 

O ambiente onde tudo é móvel e não existe infraestrutura fixa normalmente é chamado de rede móvel 
ad hoc (MANET - Mobile Ad Hoc Network —, que é o nome de um grupo de trabalho da IETF que lida 
com este domínio de problema). Para entender por que soluções especiais poderiam ser necessárias 
no ambiente ad hoc móvel, considere o fato de que, diferente de uma rede fixa, os vizinhos de determinado 
roteador ad hoc provavelmente mudam com tanta frequência quanto os nós se movem. Como qualquer 
mudança nos relacionamentos de vizinhança normalmente exige que uma mensagem de protocolo 
de roteamento seja enviada e uma nova tabela de roteamento seja calculada, é fácil ver que pode haver 
preocupações com o uso de um protocolo não otimizado para esse ambiente. Um complicador para 
esse problema é o fato de que a comunicação provavelmente será sem fios, o que consome energia, e muitos 
nós móveis provavelmente trabalharão com baterias com uma quantidade restrita de energia. As larguras 
de banda do enlace provavelmente também são restritas. Logo, a redução do overhead causado pelo envio de 
mensagens do protocolo de roteamento, inundando essas mensagens novamente para todos os vizinhos, é 
uma preocupação importante para o roteamento ad hoc. 

No momento em que este livro foi escrito, várias técnicas para otimizar o roteamento de ambientes ad 
hoc haviam sido desenvolvidas. Estas são caracterizadas de modo geral como técnicas reativas e proativas. 
O roteamento otimizado por estado do enlace (OLSR — Optimized Link State Routing) é a técnica proativa 
dominante, e seu nome dá uma boa noção do que ele é; ele é semelhante a um protocolo convencional de 
estado do enlace (como o OSPF Seção 3.3.3), com uma série de otimizações para reduzir a quantidade de 
inundação das mensagens de roteamento. Os protocolos reativos incluem o Ad Hoc On-Demand Distance 
Vector (AODV) e Dynamic MANET On Demand (DYMO), ambos baseados nos protocolos por vetor de 
distâncias descrito na Seção 3.3.2. Essas técnicas buscam reduzir a quantidade de overhead do protocolo de 
roteamento criando rotas somente quando necessário, como quando determinado nó tem tráfego para um 
destino em particular. Existe um domínio de soluções rico em que escolhas podem ser feitas, e esse domínio 
continua a ser explorado. 





4.5 Resumo 


O tema principal deste capítulo foi como tratar o crescimento continuado da Internet. A Internet 
continua conectando mais usuários, e cada usuário envia mais tráfego à medida que aplicações como 
streaming de vídeo exigem mais largura de banda. Assim, embora a Internet tenha provado ser um sis- 
tema altamente escalável, novas questões de escala continuam a exigir soluções. Além da escalabilidade, 
a Internet também precisa evoluir para dar suporte a novas funcionalidades e serviços. 

As principais questões de escala hoje são o uso eficiente do espaço de endereços e o crescimento 
das tabelas de roteamento à medida que a Internet cresce. O formato hierárquico do endereço IP com 
suas partes de rede e host, nos fornece um nível de hierarquia para controlar a escala. As áreas de rotea- 
mento fornecem outro nível de hierarquia. Os sistemas autônomos nos permitem dividir o problema 
de roteamento em duas partes, o roteamento interdomínios e intradomínio, cada qual muito menor do 
que seria o problema de roteamento total. O BGP o protocolo de roteamento interdomínios da Internet, 
tem sido marcadamente bem-sucedido ao lidar com o crescimento da Internet. 

Apesar dos muitos passos tomados para tornar o IPv4 mais escalável, fica claro que um novo formato 
de endereços, com um tamanho maior, logo será necessário. Isso requer um novo formato de datagrama 
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IP e uma nova versão do protocolo. Originalmente conhecido como IP de nova geração (IPng), esse 
novo protocolo agora é conhecido como IPv6, e fornece endereços de 128 bits com endereçamento e 
roteamento (principalmente) do tipo CIDR. Embora muitas novas funcionalidades tenham sido adi- 
cionadas no IPv6, sua principal vantagem continua sendo sua capacidade de dar suporte a um número 
extremamente grande de dispositivos endereçáveis. 

Por fim, a Internet também precisa evoluir em funcionalidade e também em tamanho. Com relação 
a este ponto, vimos três melhorias no modelo de datagramas original do IP O primeiro, o multicast, 
permite a entrega eficiente de alguns dados a grupos de receptores. Assim como o unicast, muitos dos 
desafios no multicast se relacionam a escalabilidade, e uma série de protocolos diferentes e modos 
multicast foram desenvolvidos para otimizar a escala e o roteamento em diferentes ambientes. A segunda 
melhoria, o MPLS, traz alguns dos aspectos das redes de circuitos virtuais para o IP e tem sido muito 
utilizado para estender as capacidades do IP Aplicações do MPLS variam de engenharia de tráfego até 
o suporte a redes privadas virtuais pela Internet. E, por fim, o suporte para mobilidade, que ficou longe 
das mentes dos projetistas originais do IP é cada vez mais importante à medida que mais dispositivos 
em rede, tanto hosts como roteadores, tornam-se móveis. 


E E O que vem em seguida: Implantação do IPv6 m 


Cerca de 20 anos se passaram desde que a escassez do espaço de endereços do IPv4 se tornou séria o 
suficiente para justificar as propostas para uma nova versão do IP A especificação original do IPv6 agora 
já tem mais de 15 anos. Sistemas operacionais de host habilitados com IPv6 agora são amplamente dis- 
poníveis e os principais fabricantes de roteadores oferecem graus variados de suporte para IPv6 em seus 
produtos. Mesmo assim, a implantação do IPv6 na Internet só pode ser descrita como embrionária. É in- 
teressante refletir sobre quando a implantação provavelmente começará a sério e o que isso causará. 

Um motivo pelo qual o IPv6 não foi necessário mais cedo é devido ao uso em grande escala de 
Network Address Translation (NAT), descrito anteriormente neste capítulo. À medida que os pro- 
vedores perceberam os endereços IPv4 como um recurso escasso, eles entregavam cada vez menos 
deles aos seus clientes, ou cobravam pelo número de endereços usados; os clientes respondiam 
ocultando muitos de seus dispositivos por trás de uma caixa NAT e um único endereço IPv4. Por 
exemplo, geralmente acontece que as redes domésticas com mais de um dispositivo habilitado 
com IP têm algum tipo de NAT na rede para economizar endereços. Assim, um fator que poderia 
incentivar a implantação do IPv6 seriam aplicações que não funcionam bem com NAT. Embora as 
aplicações cliente-servidor funcionem razoavelmente bem quando o endereço do cliente está es- 
condido atrás de uma caixa NAT, as aplicações peer-to-peer não se saem muito bem. Alguns exem- 
plos de aplicações que funcionariam melhor sem NAT e, portanto, se beneficiariam com políticas de 
alocação de endereço mais liberais, são jogos com múltiplos jogadores e telefonia IP Mesmo assim, 
até mesmo estas aplicações encontraram meios de lidar com NAT, e tecnologias capazes de contornar 
as limitações impostas pelo NAT agora podem ser encontradas com facilidade. 

Obter blocos de endereços IPv4 tem se mostrado cada vez mais difícil há anos, e isso é particular- 
mente notável em países fora dos Estados Unidos. À medida que a dificuldade aumenta, o incentivo para 
os provedores começarem a oferecer endereços IPv6 aos seus clientes também aumenta. Ao mesmo 
tempo, para provedores existentes, oferecer suporte ao IPv6 incorre em um custo adicional substancial, 
pois eles não deixam de dar suporte ao IPv4 quando começam a oferecer o IPv6. Isso significa, por 
exemplo, que o tamanho das tabelas de roteamento de um provedor só pode aumentar inicialmente, 
pois eles precisam transportar todos os prefixos IPv4 existentes mais os novos prefixos IPv6. 

No momento, a implantação do IPv6 tem sido liderada por redes de pesquisa. Alguns provedores 
de serviço estão começando a oferecê-lo, especialmente fora dos Estados Unidos (geralmente com 
algum incentivo dos governos nacionais).º Os roteadores comerciais e os sistemas operacionais de 


“Para informações referentes ao uso do IPv6 no Brasil podem ser encontradas no site do Comitê Gestor da Internet no Brasil 
(CGL.br) -- http://www.cgi.br/ -- ou diretamente no site do CGI dedicado a este assunto -- http://ipv6.br/(N.T) 
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hosts têm suporte IPv6 em graus variados. Parece certo que a implantação do IPv6 continuará a 
acelerar, mas também parece provável que a esmagadora maioria dos hosts e redes será apenas de 
IPv4 ainda por muitos anos. 


Leitura adicional 


Nossa primeira seleção, uma RFC de Bradner e Mankin, oferece uma visão geral informativa sobre como a Internet em 

rápido crescimento enfatizou a escalabilidade da arquitetura original, por fim resultando no IPv6. O artigo de Paxson des- 

creve um estudo de como os roteadores se comportam na Internet. Embora com mais de 15 anos de idade, ele continua 

a ser altamente citado e é um bom exemplo de como os pesquisadores estudam o comportamento dinâmico da Internet. 

O artigo final discute sobre multicast, apresentando a técnica de multicast usada originalmente no MBone. 

Bradner, S.; Mankin, A. The recommendation for the next generation IP protocol. Request for Comments 1752, janeiro de 
1995. 

Paxson, V. End-to-end routing behavior in the Internet. SIGCOMM '96, p. 25-38, agosto de 1996. 

Deering, S.; Cheriton, D. Multicast routing in datagram internetworks and extended LANs. ACM Transactions on Computer 
Systems, v. 8, n. 2, p. 85-110, maio de 1990. 


Alguns estudos experimentais interessantes do comportamento do roteamento da Internet são apre- 
sentados em Labovitz et al. [LAAJ00]. Outro artigo útil sobre a estabilidade do BGP é o de Gao e Rexford 
[GROI]. 

Uma coleção de RFCs relacionadas ao IPv6 pode ser encontrada em Bradner e Mankin [BM95], 
e a especificação IPv6 mais recente é de Deering e Hinden [DH98]. Existem dezenas de outras RFCs 
relacionadas ao IPv6. 

O Protocol Independent Multicast (PIM) é descrito em Deering et al. [DEF +96] e Fenner et al. 
[FHHKO06]; O PIM-SSM é descrito em [Bha03]. [Wil00] e [HC99] são ambos introduções ao multicast 
bastante fácil de ler, com detalhes históricos interessantes. 

O Multiprotocol Label Switching (MPLS) e os protocolos relacionados que proporcionaram seu 
desenvolvimento são descritos em Chandranmenon et al. [CV95], Rekhter et al. [RDR*97] e Davie 
etal. [DROO]. Essa última referência descreve muitas aplicações do MPLS, como engenharia de tráfego, 
recuperação rápida de falhas da rede e redes privadas virtuais. [RR06] oferece a especificação de VPNs 
MPLS/BGP uma forma de VPN da camada 3 que pode ser fornecida por redes MPLS. 

O IP móvel é definido em Perkins [Per02] para IPv4 e em Johnson et al. [JPAO4] para IPv6. Basagni 
et al. [BCGS04] oferecem uma boa base dos problemas e pesquisa em redes móveis ad hoc, enquanto 
um dos principais protocolos de roteamento MANET é descrito por Clausen et al. [CHCBO1]. 

Por fim, recomendamos as seguintes referências vivas: 


e http://www.isoc.org/internet/history/: Uma coleção de links relacionados à história da Internet, 
incluindo alguns artigos escritos pelos pesquisadores originais que criaram a Internet. 

e http://bgp.potaroo.net/: Diversos dados sobre o crescimento das tabelas de roteamento na 
Internet, incluindo a implantação do IPv6. 


Exercícios 


1. Considere a rede mostrada na Figura 4.28, em que as linhas horizontais representam provedores 
de trânsito e as linhas verticais numeradas são enlaces entre provedores. 

a. Quantas rotas para P os interlocutores BGP do provedor Q poderiam receber? 

b. Suponha que Q e P adotem a política de que o tráfego de saída é roteado para o enlace mais 
próximo do provedor do destino, minimizando assim seu próprio custo. Que caminhos 
seguirão o tráfego do host A ao host B e do host B ao host A? 

c. O que Q poderia fazer para que o tráfego B > A use o enlace mais próximo 1? 

d. O que Q poderia fazer para que o tráfego B > A passe por R? 
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A FIGURA 4.28 Rede para o Exercício 1. 
Provedor P 

2 
Provedor Q 


| 3 | 
B 


Provedor R 


2. Dê um exemplo de um arranjo de roteadores agrupados em sistemas autônomos de modo que 
o caminho com o mínimo de saltos de um ponto A para outro ponto B cruze o mesmo AS duas 
vezes. Explique o que o BGP faria com essa situação. 


tr 3. Considere que A seja o número de sistemas autônomos na Internet e que D (de diâmetro) seja o 


tamanho máximo de qualquer caminho dentro do AS. 

a. Indique o modelo de conectividade para o qual D é da ordem de log A e outro para o qual D é 
da ordem de VA. 

b. Supondo que cada número de AS tenha 2 bytes e que cada número de rede tenha 4 bytes, 
dê uma estimativa para a quantidade de dados que um interlocutor BGP deve receber para 
conhecer o caminho do AS até cada rede. Expresse sua resposta em termos de 4, De do 
número de redes N. 

4. Proponha um plano de endereçamento plausível para o IPv6 que acabe esgotando os bits 
disponíveis. Especificamente, forneça um diagrama como o da Figura 4.11, talvez com 
campos de ID adicionais, que atinja mais de 128 bits, junto com justificativas plausíveis 
para o tamanho de cada campo. Você pode considerar que os campos são divididos 
em limites de byte e que InterfaceID tenha 64 bits. (Dica: Considere os campos que se 
aproximariam da alocação máxima somente sob circunstâncias incomuns.) Você pode fazer 
isso se InterfaceID tiver 48 bits? 

5. Suponha que P Q e R sejam provedores de serviço de rede com as respectivas alocações de 
endereço CIDR C1.0.0.0/8, C2.0.0.0/8 e C3.0.0.0/8. Os clientes de cada provedor inicialmente 
recebem alocações de endereço que são um subconjunto daquelas do provedor. P tem os 
seguintes clientes: 

PA, com alocação C1.A3.0.0/16 

PB, com alocação C1.B0.0.0/12. 

Q tem os seguintes clientes: 

QA, com alocação C2.04.10.0/20 

QB, com alocação C2.0B.0.0/16. 

Suponha que não haja outros provedores ou clientes. 

a. Forneça as tabelas de roteamento para P Q e R supondo que cada provedor se conecte aos 
outros dois. 

b. Agora suponha que P esteja conectado a Q e que Q esteja conectado a R, mas P e R não 
estejam conectados diretamente. Forneça as tabelas para P e R. 

c. Suponha que o cliente PA adquira um enlace direto para Q, e que QA adquira um 
enlace direto para P além dos enlaces existentes. Forneça as tabelas 
para P e Q, ignorando R. 

6. No problema anterior, suponha que cada provedor se conecte aos outros dois. Suponha 
que o cliente PA mude para o provedor Q e o cliente QB mude para o provedor R. 

Use a regra da correspondência mais longa do CIDR para obter as tabelas de roteamento 

para todos os três provedores que permitem que PA e QB façam essa mudança sem 

que haja renumerações. 

7. Suponha que a maior parte da Internet use alguma forma de endereçamento geográfico, mas 
que uma organização internacional grande tenha um único endereço de rede IP e roteie seu 
tráfego interno por seus próprios enlaces. 





10. 


Z n. 


12. 


13. 


14. 


(15. 
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a. Explique a ineficiência do roteamento para o tráfego de entrada da organização que é 
inerente a essa situação. 

b. Explique como a organização poderia resolver esse problema para o tráfego 
de saída. 

c. Para que o seu método do item anterior funcione para o tráfego de entrada, o que teria 
que acontecer? 

d. Suponha que a grande organização agora mude seu endereçamento para endereços 
geográficos separados para cada escritório. Como deverá ser sua estrutura 
de roteamento interna se o tráfego interno ainda tiver que ser roteado 
internamente? 

O sistema telefônico usa endereçamento geográfico. Por que você acha que isso não foi adotado 

como algo óbvio pela Internet? 

Suponha que um pequeno ISP X pague a um ISP maior A para conectá-lo ao restante da Internet 

e também pague a outro ISP B para fornecer uma conexão reserva à Internet, caso ele perca a 

conectividade pelo ISP A. Se o ISP X descobrir um caminho para algum prefixo via ISP A, ele 

deverá anunciar esse caminho para o ISP B? Por quê? 

Suponha que um local A seja multihomed, por ter duas conexões com a Internet por meio de 

dois provedores diferentes, P e Q. O endereçamento baseado em provedor é usado como no 

Exercício 5, e que os endereços de A sejam atrubuídos por P. Q tem uma entrada de roteamento 

CIDR para A, do tipo correspondência mais longa. 

a. Descreva que tráfego de entrada poderia ser transmitido na conexão A-Q. Considere casos 
onde Q anuncia e não anuncia A para o mundo usando BGP 

b. Qual é o anúncio mínimo de sua rota para A que Q precisa fazer a fim de que todo o tráfego de 
entrada alcance A via Q se o enlace P-A for interrompido? 

c. Que problemas precisam ser contornados se A tiver que usar os dois enlaces para o seu 
tráfego de saída? 

Suponha que uma rede N dentro de uma organização grande A adquira sua própria conexão 

direta com um Provedor de Serviços de Internet, além da conexão existente via A. Considere que 

R1 seja o roteador que conecta N ao seu próprio provedor, e que R2 seja o roteador conectando N 

ao restante de A. 

a. Supondo que N continue sendo uma sub-rede de A, como R1 e R2 devem ser configurados? 
Que limitações ainda existiriam com o uso, por N, da sua conexão separada? A seria 
impedido de usar a conexão de N? Especifique sua configuração em termos do que R1 e R2 
devem anunciar e com quais caminhos. Considere que um mecanismo do tipo BGP esteja 
disponível. 

b. Agora suponha que N receba seu próprio número de rede; como isso muda a sua resposta 
para o item (a)? 

c. Descreva uma configuração de roteador que permita a A usar o enlace de N quando o seu 
próprio enlace não puder ser utilizado. 

Como os roteadores determinam que um pacote IP de entrada deve ser enviado por multicast? 

Dê as respostas tanto para IPv4 como para IPv6. 

Suponha que um grupo de multicast deva ser privado para determinado domínio de roteamento. 

Um endereço multicast IP pode ser atribuído ao grupo sem consultar outros domínios de forma 

que não haja risco de conflitos? 

Sob que condições um host que não seja um roteador em uma Ethernet poderia receber um 

pacote multicast IP para um grupo de multicast ao qual ele não se juntou? 

Considere a inter-rede de exemplo que aparece na Figura 4.29, em que as origem D 

e E enviam pacotes para o grupo de multicast G, cujos membros estão sombreados 

em cinza. Mostre as árvores de multicast de caminho mais curto para cada 

origem. 
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FIGURA 4.29 Inter-rede de exemplo para o Exercício 15. 


16. Considere a inter-rede de exemplo mostrada na Figura 4.30, em que as origens S1 e S2 enviam 
pacotes para o grupo de multicast G, cujos membros são sombreados em cinza. Mostre as 
árvores de multicast de caminho mais curto para cada origem. 


R8 
| — 
= R1 | 


— R7 


s1 | 

R2 — 
= R6 
S2 


R4 R5 


FIGURA 4.30 Rede de exemplo para o Exercício 16. 


17. Suponha que o host A esteja enviando dados para um grupo de multicast; os destinatários são os 
nós folha de uma árvore com raiz em A, com profundidade N e com cada nó que não é uma folha 
tendo k filhos; portanto, existem k“ destinatários. 
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a. Quantas transmissões por enlaces individuais são envolvidas se A envia uma mensagem de 
multicast para todos os destinatários? 

b. Quantas transmissões por enlaces individuais são envolvidas se A envia mensagens de 
unicast a cada destinatário individual? 

c. Suponha que A envie mensagens para todos os destinatários, mas algumas mensagens 
sejam perdidas e a retransmissão seja necessária. Em termos de transmissões por enlaces 
individuais, retransmissões unicast para que fração dos destinatários seria equivalente a uma 
retransmissão multicast para todos os destinatários? 

A Internet existente depende em muitos aspectos dos participantes serem bons “cidadãos da 

rede” - cooperando em completa aderência aos protocolos padrão. 

a. No esquema PIM-SM, quem determina quando criar uma árvore de origem específica? Como 
isso poderia ser um problema? 

b. No esquema PIM-SSM, quem determina quando criar uma árvore de origem específica? Por 
que isso supostamente não é um problema? 

a. Desenhe uma inter-rede de exemplo onde a rota BIDIR-PIM de um roteador de origem para o 
roteador de um membro do grupo é mais longa do que a rota de origem específica PIM-SM. 

b. Desenhe um exemplo onde elas sejam iguais. 

Determine se as seguintes notações de endereço IPv6 estão corretas ou não: 

a. ::0F53:6382:AB00:67DB:BB27:7332 

b. 7803:42F2:::88EC:D4BA:B75D:11CD 

c. ::4BA8:95CC::DB97:4EAB 

d. 74DC::02BA 

e. ::00FF:128.112.92.116 

Rótulos MPLS normalmente possuem 20 bits de extensão. Explique por que isso fornece rótulos 

suficientes quando o MPLS é usado para o encaminhamento baseado no destino. 

Às vezes, afirma-se que o MPLS melhora o desempenho do roteador. Explique por que isso 

poderia ser verdade e sugira motivos para que, na prática, isso possa não acontecer. 

Suponha que sejam necessários 32 bits para transportar cada rótulo MPLS que é adicionado a 

um pacote quando o cabeçalho de “recheio” da Figura 4.20(b) for usado. 

a. Quantos bytes adicionais são necessários para enviar um pacote por túnel usando as técnicas 
de MPLS descritas na Seção 4.3.3? 

b. Quantos bytes adicionais são necessários, no mínimo, para enviar um pacote por túnel 
usando um cabeçalho IP adicional, conforme descrito na Seção 3.2.9? 

c. Calcule a eficiência do uso de largura de banda para cada uma das duas técnicas de 
tunelamento quando o tamanho médio do pacote é de 300 bytes. Repita o cálculo para 
pacotes de 64 bytes. A eficiência da largura de banda é definida como (bytes de payload 
transportados) + (total de bytes transportados). 

A REC 791 descreve o Internet Protocol (IP) e inclui duas opções para o roteamento na origem. 

Descreva três desvantagens do uso das opções de rota de origem do IP em comparação com o 

uso do MPLS para o roteamento explícito. (Dica: O cabeçalho IP incluindo as opções, pode ter no 

máximo 15 palavras (words) de extensão.)!º 

O DHCP permite que um computador adquira um novo endereço IP sempre que se mover para 

uma nova sub-rede. Por que isso nem sempre é suficiente para resolver as necessidades de 

comunicação dos hosts móveis? 

Qual é a principal desvantagem de exigir que o tráfego destinado a um nó móvel seja enviado 

primeiro para o seu agente nativo? 

O IP móvel permite que um agente nativo informe a um nó correspondente um novo endereço 

de tratamento para o nó móvel. Como esse mecanismo poderia ser usado para roubar tráfego? 

Como ele poderia ser usado para direcionar uma avalanche de tráfego malicioso para outro nó? 


Uma palavra (word) =2 bytes = 16 bits. 


Protocolos fim a fim 


Vitória é a flor colorida, bela e brilhante. Transporte é o talo 
sem o qual ela nunca teria florescido. 
Winston Churchill 


E E Problema: fazer com que os processos se comuniquem E 


Os três capítulos anteriores descreveram diversas tecnologias que podem ser usadas para 
conectar uma coleção de computadores, variando desde redes Ethernet simples e redes 

sem fios até inter-redes em escala global. O próximo problema é transformar esse serviço 

de entrega de pacotes host a host em um canal de comunicação processo a processo. Esse 

é o papel desempenhado pelo nível de transporte da arquitetura de rede, que, por dar suporte 

à comunicação entre os programas de aplicação executados nos nós finais, às vezes é chamado 

de protocolo fim a fim. 

Duas forças modelam o protocolo fim a fim. De cima, os processos no nível de aplicação que 
usam seus serviços possuem certos requisitos. A lista a seguir apresenta algumas das propriedades 
comuns que se pode esperar que um protocolo de transporte ofereça: 


e Garantir a entrega da mensagem. 

e Entregar mensagens na mesma ordem em que são enviadas. 

e Entregar no máximo uma cópia de cada mensagem. 

e Admitir mensagens arbitrariamente grandes. 

e Admitir sincronização entre o emissor e o receptor. 

e Permitir que o receptor aplique controle de fluxo sobre o emissor. 
e Admitir múltiplos processos de aplicação em cada host. 


Observe que essa lista não inclui todas as funcionalidades que os processos da aplicação 
poderiam querer da rede. Por exemplo, ela não inclui recursos de segurança, como autenticação 
ou cifração, que normalmente são oferecidos por protocolos que ficam acima do nível de 
transporte. 

De baixo, a rede subjacente sobre a qual o protocolo de transporte opera tem certas limitações no 
nível de serviço que ela pode oferecer. Algumas das limitações mais comuns da rede são que ela 
pode 


e Descartar mensagens. 

e Reordenar mensagens. 

e Entregar cópias duplicadas de determinada mensagem. 

e Limitar mensagens a algum tamanho finito. 

e Entregar mensagens após um atraso arbitrariamente longo. 


Essa rede é considerada como oferecendo um nível de serviço de melhor esforço, conforme 
exemplificado pela Internet. 

O desafio, portanto, é desenvolver algoritmos que transformem as propriedades menos que 
desejáveis da rede subjacente no alto nível de serviço exigido pelos programas de aplicação. 
Diferentes protocolos de transporte empregam diferentes combinações desses algoritmos. Este 
capítulo examina esses algoritmos no contexto de quatro serviços representativos — um serviço 
de demultiplexação assíncrono simples, um serviço de fluxo de bytes confiável, um serviço de 
solicitação /resposta e um serviço para aplicações em tempo real. 
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No caso dos serviços de demultiplexação e de fluxo de bytes, usamos o User Datagram Protocol 
(UDP) e o Transmission Control Protocol (TCP) da Internet, respectivamente, para ilustrar 

como esses serviços são fornecidos na prática. No caso de um serviço de solicitação /resposta, 
discutimos o papel que ele desempenha em uma chamada de procedimento remoto (RPC — 
Remote Procedure Call) e quais recursos isso inclui. Essa discussão termina com uma descrição de 
dois protocolos RPC bastante utilizados: SunRPC e DCE-RPC. 

Por fim, as aplicações de tempo real fazem demandas específicas ao protocolo de transporte, 
como a necessidade de transportar informações de tempo que permitam que amostras de áudio 
e vídeo sejam reproduzidas no instante correto do tempo. Examinamos os requisitos impostos 
por aplicações nesse tipo de protocolo e o exemplo mais utilizado, o Real-Time Transport Protocol 
(RTP). 


5.1 Demultiplexador simples (UDP) 


O protocolo de transporte mais simples possível é aquele que estende o serviço de entrega host a host 
da rede subjacente a um serviço de comunicação processo a processo. Provavelmente existem muitos 
processos sendo executados em qualquer host, de modo que o protocolo precisa acrescentar um nível 
de demultiplexação, permitindo, assim, que vários processos de aplicação em cada host compartilhem 
a rede. Exceto por esse requisito, o protocolo de transporte não acrescenta outra funcionalidade ao 
serviço de melhor esforço fornecido pela rede subjacente. O User Datagram Protocol da Internet é um 
exemplo desse tipo de protocolo de transporte. 

A única questão interessante em tal protocolo é o formato do endereço usado para identificar o 
processo de destino. Embora seja possível que os processos identifiquem diretamente um ao outro 
com um identificador de processo (pid) atribuído pelo SO, essa técnica só é prática em um sistema 
distribuído fechado, em que um único SO é executado em todos os hosts e atribui a cada processo 
um identificador exclusivo. Uma técnica mais comum, e que é usada pelo UDP é que os processos 
identifiquem indiretamente uns aos outros usando um localizador abstrato, normalmente chamado de 
porta. A ideia básica é que um processo de origem envie uma mensagem a uma porta e que o processo 
de destino receba a mensagem de uma porta. 

O cabeçalho para um protocolo fim a fim que implementa essa função de demultiplexação normal- 
mente contém um identificador (porta) do emissor (origem) e do receptor (destino) da mensagem. Por 
exemplo, o cabeçalho UDP é mostrado na Figura 5.1. Observe que o campo de porta UDP tem apenas 
16 bits de extensão. Isso significa que existem até 64K portas possíveis, nitidamente não o bastante para 
identificar todos os processos em todos os hosts na Internet. Felizmente, as portas não são interpretadas 
por toda a Internet, mas somente em um único host. Ou seja, um processo é de fato identificado por 
uma porta em algum host em particular - um par (porta, host). De fato, esse par constitui a chave de 
demultiplexação para o protocolo UDP 

O próximo problema é como um processo descobre a porta do processo para o qual deseja enviar 
uma mensagem. Normalmente, um processo cliente inicia uma troca de mensagem com um processo 
servidor. Quando um cliente tiver entrado em contato com um servidor, o servidor reconhece a porta do 
cliente (pelo campo PortaOrigem contido no cabeçalho da mensagem) e pode lhe responder. O problema 
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FIGURA 5.1 Formato do cabeçalho UDP. 
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real, portanto, é como o cliente descobre a porta do servidor em primeiro lugar. Uma técnica comum 
é que o servidor aceite mensagens em uma porta bem conhecida. Ou seja, cada servidor recebe suas 
mensagens em alguma porta fixa que é publicada abertamente, de forma muito parecida com o serviço 
de telefone de emergência disponível nos Estados Unidos, que corresponde ao número de telefone bem 
conhecido 911.! Na Internet, por exemplo, o Domain Name Server (DNS) recebe mensagens na porta 53 
em cada host, o serviço de correio eletrônico (e-mail) escuta mensagens na porta 25 e o programa talk do 
Unix aceita mensagens na porta 517, e assim por diante. Esse mapeamento é publicado periodicamente 
em uma RFC e está disponível na maioria dos sistemas Unix no arquivo /etc/services. As vezes, uma 
porta bem conhecida é apenas o ponto de partida para a comunicação: o cliente e o servidor usam a 
porta bem conhecida para combinar sobre alguma outra porta que eles usarão para a comunicação 
seguinte, deixando a porta bem conhecida livre para outros clientes. 

Uma estratégia alternativa é generalizar essa ideia, de modo que haja somente uma única porta bem 
conhecida — aquela em que o serviço mapeador de porta aceita mensagens. Um cliente enviaria uma 
mensagem à porta bem conhecida do mapeador de porta, perguntando sobre a porta que ele deve usar 
para falar com “qualquer que seja” o serviço, e o mapeador de porta retorna a porta apropriada. Essa 
estratégia facilita a troca de porta,associada a diferentes serviços ao longo do tempo e permite que cada 
host use uma porta diferente para o mesmo serviço. 

Conforme mencionamos, uma porta é puramente uma abstração. O modo exato como ela é imple- 
mentada difere de um sistema para outro ou, mais precisamente, de um SO para outro. Por exemplo, a 
API de sockets descrita no Capítulo 1 é uma implementação de exemplo das portas. Normalmente, uma 
porta é implementada por uma fila de mensagens, como ilustra a Figura 5.2. Quando uma mensagem 
chega, o protocolo (por exemplo, UDP) coloca a mensagem no final da fila. Se a fila estiver cheia, a 
mensagem é descartada. Não existe mecanismo de controle de fluxo no UDP para dizer ao transmissor 
para reduzir a taxa de envio. Quando um processo da aplicação deseja receber uma mensagem, uma 
delas é removida da frente da fila. Se a fila estiver vazia, o processo é bloqueado até que uma mensagem 
esteja disponível. 

Por fim, embora o UDP não implemente controle de fluxo ou entrega confiável/ordenada, ele oferece 
mais uma função além da demultiplexação de mensagens para algum processo da aplicação — ele 
também garante a exatidão da mensagem pelo uso de uma soma de verificação. (A soma de verificação 
UDP é opcional no IPv4, mas é obrigatória no IPv6.) O algoritmo básico de soma de verificação do UDP 


1No Brasil, o número de emergência bem conhecido é o 190.(N.T.) 
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é o mesmo usado pelo IP conforme definido na Seção 2.4.2 — ou seja, ele soma um conjunto de palavras 
de 16 bits usando a aritmética de complemento de um e calcula o complemento de um do resultado. 
Mas os dados de entrada que são usados para a soma de verificação são um pouco contraintuitivos. 

A soma de verificação do UDP usa como entrada o cabeçalho UDP o conteúdo do corpo da men- 
sagem e algo chamado pseudocabeçalho. O pseudocabeçalho consiste em três campos do cabeçalho 
IP — o número de protocolo, endereço IP de origem e endereço IP de destino — mais o campo de com- 
primento do UDP (Sim, o campo de comprimento do UDP é incluído duas vezes no cálculo da soma de 
verificação.) A motivação por trás de ter o pseudocabeçalho é verificar se essa mensagem foi transportada 
entre os dois terminais corretos. Por exemplo, se o endereço IP de destino foi modificado enquanto o 
pacote estava em trânsito, fazendo com que o pacote fosse encaminhado erroneamente, esse fato seria 
detectado pela soma de verificação do UDP 


5.2 Fluxo de bytes confiável (TCP) A 


TCP 

Ao contrário de um protocolo de demultiplexação simples como o UDP um protocolo de transporte mais 
sofisticado é aquele que oferece um serviço confiável, orientado a conexão, de fluxo de bytes. Esse serviço 
provou-se útil para uma grande variedade de aplicações, pois libera a aplicação de ter que se preocupar 
com dados perdidos ou reordenados. O Transmission Control Protocol (TCP) da Internet provavelmente 
é o protocolo desse tipo mais utilizado; ele também é o protocolo mais cuidadosamente trabalhado. 
É por esses dois motivos que esta seção estuda o TCP em detalhes, embora sejam identificadas e dis- 
cutidas escolhas de projeto alternativas ao final da seção. 

Em termos das propriedades dos protocolos de transporte dadas na declaração do problema no início 
deste capítulo, o TCP garante a entrega confiável e ordenada de um fluxo de bytes. Ele é um protocolo 
full-duplex, significando que cada conexão TCP suporta um par de fluxos de bytes, cada um fluindo 
em um sentido. Ele também inclui um mecanismo de controle de fluxo para cada um desses fluxos 
de bytes, que permite ao receptor limitar quantos dados o emissor pode transmitir em determinado 
momento. Finalmente, como o UDP o TCP apresenta um mecanismo de demultiplexação que per- 
mite que vários programas de aplicação em determinado host realizem uma conversa com seus pares. 
Além dos recursos apresentados, o TCP também implementa um mecanismo de controle de conges- 
tionamento altamente trabalhado (e ainda em evolução). A ideia desse mecanismo é regular a rapidez 
com que o TCP envia dados, não para evitar que o transmissor inunde o receptor, mas para evitar que o 
transmissor sobrecarregue a rede. Uma descrição do mecanismo de controle de congestionamento do 
TCP será deixada para o Capítulo 6, quando o discutimos no contexto mais amplo de como os recursos 
da rede são alocados de forma justa. 


Como muitas pessoas confundem controle de congestionamento com controle de fluxo, vamos reforçar a 
diferença. Controle de fluxo envolve impedir que os transmissores sobrecarreguem os receptores. Controle 


de congestionamento envolve impedir que muitos dados sejam injetados na rede, fazendo com que switches 
ou enlaces fiquem sobrecarregados. Portanto, o controle de fluxo é um problema fim a fim, enquanto o 
controle de congestionamento se preocupa com o modo como hosts e redes interagem. 





5.2.1 Problemas fim a fim 


No núcleo do TCP está o algoritmo de janela deslizante. Embora este seja o mesmo algoritmo básico 
que vimos na Seção 2.5.2, como o TCP é executado sobre a Internet em vez de um enlace ponto a ponto, 
existem muitas diferenças importantes. Esta subseção identifica essas diferenças e explica como elas 
complicam o TCP As próximas subseções, então, descrevem como o TCP resolve estas e outras com- 
plicações. 

Primeiro, enquanto o algoritmo de janela deslizante apresentado na Seção 2.5.2 é executado sobre 
um único enlace físico que sempre conecta os mesmos dois computadores, o TCP admite conexões 
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lógicas entre processos que estão sendo executados em dois computadores quaisquer na Internet. 
Isso significa que o TCP precisa de uma fase explícita de estabelecimento de conexão, durante a qual 
os dois lados da conexão combinam em trocar dados um com o outro. Essa diferença é semelhante a 
ter que discar para um terceiro, em vez de ter uma linha telefônica dedicada. O TCP também tem uma 
fase explícita de encerramento de conexão. Uma das coisas que acontece durante o estabelecimento da 
conexão é que as duas partes estabelecem algum estado compartilhado para permitir que o algoritmo 
de janela deslizante se inicie. O encerramento da conexão é necessário para que cada host saiba que 
ele pode liberar esse estado. 

Segundo, enquanto um único enlace físico que sempre conecta os mesmos dois computadores tem 
um tempo de ida e volta (RTT) fixo, as conexões TCP provavelmente têm tempos de ida e volta bastante 
diferentes. Por exemplo, uma conexão TCP entre um host em São Francisco e um host em Boston, que 
estão separados por vários milhares de quilômetros, poderia ter um RTT de 100 ms, enquanto uma 
conexão TCP entre dois hosts na mesma sala, afastados por alguns metros, poderia ter um RTT de apenas 
1 ms. O mesmo protocolo TCP precisa ser capaz de dar suporte a essas duas conexões. Para piorar as 
coisas ainda mais, a conexão TCP entre os hosts em São Francisco e Boston poderia ter um RTT de 
100 ms às 3h00 da manhã, mas um RTT de 500 ms às 15h00. As variações no RTT são ainda possíveis 
durante uma única conexão TCP que dure apenas alguns minutos. O que isso significa para o algoritmo 
de janela deslizante é que o mecanismo de expiração de temporizador que dispara as retransmissões 
precisa ser adaptativo. (Certamente, a expiração de temporizador para um enlace ponto a ponto deve 
ser um parâmetro configurável, mas não é necessário adaptar esse temporizador para um par de nós 
em particular.) 

Uma terceira diferença é que os pacotes podem ser reordenados à medida que cruzam a Internet, 
mas isso não é possível em um enlace ponto a ponto, em que o primeiro pacote colocado em uma 
ponta do enlace precisa ser o primeiro a aparecer na outra ponta. Os pacotes que estão ligeiramente 
fora de ordem não causam problema, pois o algoritmo de janela deslizante pode reordenar pacotes 
corretamente usando o número de sequência. O problema real é até que ponto os pacotes fora de 
ordem podem chegar ou, em outras palavras, com que atraso um pacote pode chegar ao destino. Na 
pior das hipóteses, um pacote pode ser atrasado na Internet até que o campo de tempo de vida (TTL) 
do IP expire, quando o pacote será descartado (e, portanto, não existe perigo de chegar atrasado). 
Sabendo que o IP descarta pacotes depois que seu TTL expira, o TCP assume que cada pacote tem 
um tempo de vida máximo. O tempo de vida exato, conhecido como tempo de vida máximo do 
segmento (MSL — Maximum Segment Lifetime), é uma escolha de engenharia. O valor recomendado 
atual é de 120 segundos. Lembre-se que o IP não impõe diretamente esse valor de 120 segundos; 
essa é simplesmente uma estimativa conservadora que o TCP faz sobre o tempo que um pacote 
poderia viver na Internet. A implicação é significativa - o TCP precisa estar preparado para pacotes 
muito antigos que, de repente, aparecem no receptor, potencialmente confundindo o algoritmo de 
janela deslizante. 

Em quarto lugar, os computadores conectados a um enlace ponto a ponto geralmente são proje- 
tados para suportar aquele enlace. Por exemplo, se o produto atraso x largura de banda de um enlace 
é calculado para ser 8 KB - significando que um tamanho de janela é selecionado para permitir que 
até 8 KB de dados não estejam confirmados em determinado momento -, então é provável que os 
computadores em cada extremidade do enlace sejam capazes de manter em buffer até 8 KB de dados. 
Projetar o sistema de outra forma seria tolice. Por outro lado, quase todo tipo de computador pode ser 
conectado à Internet, tornando a quantidade de recursos dedicados a qualquer conexão TCP altamente 
variável, especialmente quando se considera que qualquer host potencialmente pode aceitar centenas 
de conexões TCP ao mesmo tempo. Isso significa que o TCP precisa incluir um mecanismo que cada 
lado utilize para “descobrir” quais recursos (por exemplo, quanto espaço em buffer) o outro lado é capaz 
de alocar à conexão. Este é o problema do controle de fluxo. 

Em quinto lugar, como o lado transmissor de um enlace conectado diretamente não pode enviar 
mais rapidamente do que a largura de banda suportada pelo enlace, e apenas um host está injetando 
dados no enlace, não é possível congestionar o enlace involuntariamente. Em outras palavras, a carga 
no enlace é visível na forma de uma fila de pacotes no emissor. Ao contrário, o lado emissor de uma 
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conexão TCP não tem ideia de quais enlaces serão atravessados para alcançar o destino. Por exemplo, 
a máquina emissora poderia estar conectada diretamente a uma rede Ethernet relativamente rápida — 
e capaz de enviar dados a uma taxa de 100 Mbps -, mas em algum ponto no meio da rede, um enlace 
T1 de 1,5 Mbps precisa ser atravessado. E, para piorar ainda mais as coisas, os dados sendo gerados 
por muitas fontes diferentes poderiam estar tentando atravessar esse mesmo enlace lento. Isso leva ao 
problema do congestionamento da rede. A discussão desse tópico será deixada para o Capítulo 6. 

Concluímos esta discussão dos problemas fim a fim comparando a técnica do TCP para oferecer um 
serviço de entrega confiável/ordenado com a técnica usada pelas redes X.25. No TCP considera-se que 
a rede IP subjacente não é confiável e que ela entrega mensagens fora de ordem; o TCP usa o algoritmo 
de janela deslizante na conexão fim a fim para oferecer a entrega confiável/ordenada. Em comparação, 
redes X.25 usam o protocolo de janela deslizante dentro da rede, na conexão hop a hop. A suposição 
por trás dessa abordagem é que, se as mensagens são entregues de modo confiável e em ordem entre 
cada par de nós ao longo do caminho entre o host de origem e o host de destino, então o serviço fim a 
fim também garante a entrega confiável/ordenada. 

O problema com essa última abordagem é que uma sequência de garantias hop a hop não neces- 
sariamente traz benefícios com relação a uma garantia fim a fim. Primeiro, se um enlace heterogêneo 
(digamos, Ethernet) for adicionado em uma extremidade do caminho, então não há garantias de que 
esse hop preservará o mesmo serviço dos outros hops. Segundo, só porque o protocolo de janela des- 
lizante garante que as mensagens são entregues corretamente do nó A para o nó B, e depois do nó B 
para o nó C, isso não garante que o nó B se comporta perfeitamente. Por exemplo, sabe-se que os nós 
da rede introduzem erros nas mensagens enquanto as transferem de um buffer de entrada para um 
buffer de saída. Eles também são conhecidos por reordenar acidentalmente as mensagens. Como uma 
consequência dessas pequenas janelas de vulnerabilidade, ainda é necessário oferecer verificações fim 
a fim de fato para garantir um serviço confiável/ordenado, embora os níveis mais baixos do sistema 
também implementem essa funcionalidade. 


Esta discussão serve para ilustrar um dos princípios mais importantes no projeto de sistemas — o argumento 
fim a fim. Resumindo, o argumento fim a fim diz que uma função (em nosso exemplo, oferecer entrega 
confiável/ordenada) não deverá ser fornecida nos níveis inferiores do sistema, a menos que possa ser 
completa e corretamente implementada nesse nível. Portanto, essa regra é um argumento em favor da 


abordagem do TCP/IP Porém, essa regra não é absoluta. Ela permite que funções sejam fornecidas de forma 
incompleta, em um nível mais baixo, como uma otimização de desempenho. É por isso que é perfeitamente 
coerente com o argumento fim a fim o ato de realizar detecção de erros (por exemplo, usando CRC) entre 
pares de hops ; a detecção e a retransmissão de um único pacote corrompido por um hop é preferível a ter 
que retransmitir um arquivo inteiro fim a fim. 





5.2.2 Formato do segmento 


O TCP é um protocolo orientado a bytes, o que significa que o emissor escreve bytes em uma conexão 
TCP e o receptor lê bytes da conexão TCP Embora o “fluxo de bytes” descreva o serviço que o TCP oferece 
aos processos da aplicação, o TCP por si só, não transmite bytes individuais pela Internet. Em vez disso, 
o TCP no host de origem mantém em buffer bytes suficientes provenientes do processo emissor para 
preencher um pacote de tamanho razoável e depois envia esse pacote para seu par no host de des- 
tino. O TCP no host de destino, então, transfere todo o conteúdo do pacote para o buffer de recepção, 
e o processo receptor lê dados desse buffer como desejar. Essa situação é ilustrada na Figura 5.3, que, 
para simplificar, mostra os dados fluindo apenas em um sentido. Lembre-se que, em geral, uma única 
conexão TCP admite fluxos de byte fluindo nos dois sentidos. 

Os pacotes trocados entre pares TCP na Figura 5.3 são chamados segmentos, pois cada um trans- 
porta um segmento do fluxo de bytes. Cada segmento TCP contém o cabeçalho representado de forma 
esquemática na Figura 5.4. A relevância da maioria desses campos se tornará clara no decorrer desta 
seção. Por enquanto, vamos simplesmente apresentá-los. 


Capítulo 5 * Protocolos fim afim 245 





TER 


Processo da aplicação 


L ] 
LC] Escreve 





FIGURA 5.3 Como o TCP gerencia um fluxo 
de bytes. 


Processo da aplicação 


[ Lê 












E bytes : bytes 
C] LI] 
TCP TCP 
Buffer de envio Buffer de recepção 
Segmento Segmento | --- | Segmento 
Transmite segmentos 
0 4 10 16 31 FIGURA 5.4 Formato do cabeçalho TCP. 
PortaOrig PortaDest 
NúmeroSeq | 
Confirmação | 
TamCab 0 Flags JanelaAnunciada | 
SomavVerif PtrUrg 


Opções (variável) 


Dados 


Os campos SrcPort e DstPort identificam as portas de origem e de destino, respectivamente, assim 
como no UDP Esses dois campos, mais os endereços IP de origem e destino, são combinados para 
identificar univocamente cada conexão TCP ou seja, a chave demux do TCP é dada pela quádrupla 


<PortaOrig, EndlPOrig, PortaDest, EndilPDest- 


Observe que, como as conexões TCP vêm e vão, é possível que uma conexão entre um par qualquer 
de portas seja estabelecida, usada para enviar e receber dados, fechada, e depois, em outra ocasião, 
que o mesmo par de portas esteja envolvido em uma segunda conexão. Às vezes, referimo-nos a essa 
situação como duas ocorrências diferentes da mesma conexão. 

Os campos Confirmação, NúmeroSeg e JanelaAnunciada estão todos envolvidos no algoritmo de 
janela deslizante do TCP Como o TCP é um protocolo orientado a bytes, cada byte de dados tem um 
número de sequência. O campo NúmeroSeqg contém o número de sequência para o primeiro byte de 
dados transportado nesse segmento, e os campos Confirmação e JanelaAnunciada transportam in- 
formações sobre o fluxo de dados indo no outro sentido. Para simplificar nossa discussão, ignoramos 
o fato de que os dados podem fluir nas duas direções, e nos concentramos nos dados que têm um 
NúmeroSeq em particular fluindo em um sentido e os valores de Confirmação e JanelaAnunciada 
fluindo no sentido oposto, conforme ilustra a Figura 5.5. O uso desses três campos é descrito com 
mais detalhes na Seção 5.2.4. 

O campo Flags de 6 bits é usado para repassar informações de controle entre pares TCP. Os flags 
(marcadores) possíveis incluem SYN, FIN, RESET, PUSH, URG e ACK. Os flags SYN e FIN são usados 


246 REDES DE COMPUTADORES ELSEVIER 


Dados (NúmeroSeq) FIGURA 5.5 Ilustração simplificada (mostrando apenas 
IL ça q uma direção) do processo do TCP com fluxo de dados 
. em um sentido e ACKs no outro. 
Emissor Receptor 


Confirmação + 
JanelaAnunciada 


no estabelecimento e encerramento de uma conexão TCP respectivamente. Seu uso é descrito na Seção 
5.2.3. O flag ACK é colocado em 1 toda vez que o campo Confirmação é válido, implicando que o receptor 
deve prestar atenção a ele. O flag URG significa que esse segmento contém dados urgentes. Quando esse 
flag é marcado, o campo PtrUrg indica onde começam os dados não urgentes contidos nesse segmento. 
Os dados urgentes estão contidos no início do corpo do segmento, até, e incluindo, um valor de PtrUrg 
bytes no segmento. O flag PUSH significa que o emissor invocou a operação push, que indica ao lado 
receptor do TCP que ele deve notificar o processo receptor sobre esse fato. Discutiremos melhor sobre 
esses dois recursos na Seção 5.2.7. Finalmente, o flag RESET significa que o receptor ficou confuso — por 
exemplo, porque recebeu um segmento que ele não esperava receber — e deseja abortar a conexão. 
Finalmente, o campo Checksum é usado exatamente da mesma maneira que para o UDP - ele é 
calculado sobre o cabeçalho TCP os dados TCP e o pseudocabeçalho, que é composto pelos campos 
de endereço de origem, endereço de destino e comprimento do cabeçalho IP A soma de verificação é 
exigida para o TCP tanto no IPv4 como no IPv6. Além disso, como o cabeçalho TCP tem tamanho variável 
(opções podem ser inseridas após os campos obrigatórios), um campo TamCab é incluído para indicar 
o tamanho do cabeçalho em palavras de 32 bits. Esse campo também é conhecido como campo de 
Deslocamento, pois mede o deslocamento a partir do início do pacote até o início dos dados. 


5.2.3 Estabelecimento e término da conexão 


Uma conexão TCP começa com um cliente (chamador) realizando uma abertura ativa em um servidor 
(chamado). Supondo que o servidor tenha feito anteriormente uma abertura passiva, os dois lados 
iniciam um processo de troca de mensagens para estabelecer a conexão. (Lembre-se, do Capítulo 1, que 
uma parte querendo iniciar uma conexão realiza uma abertura ativa, enquanto uma parte disposta a 
aceitar uma conexão realiza uma abertura passiva.) Somente depois que essa fase de estabelecimento 
de conexão termina é que os dois lados começam a enviar dados. De modo semelhante, assim que 
um participante termina de enviar dados, ele fecha uma direção da conexão, o que faz com que o TCP 
inicie o envio de uma sequência de mensagens de término de conexão. Observe que, embora o es- 
tabelecimento da conexão seja uma atividade assimétrica (um lado realiza uma abertura passiva e o 
outro realiza uma abertura ativa), o encerramento da conexão é simétrico (cada lado precisa fechar a 
conexão independentemente).? Portanto, é possível que um lado tenha fechado a conexão, significando 
que ele não pode mais enviar dados, mas o outro lado mantenha a outra metade da conexão bidirecional 
aberta e continue a enviar dados. 


Three-way Handshake 

O algoritmo usado pelo TCP para estabelecer e terminar uma conexão é chamado de three-way hands- 
hake, ou apresentação em três vias. Primeiro, descrevemos o algoritmo básico e depois mostramos 
como ele é usado pelo TCP O three-way handshake envolve a troca de três mensagens entre o cliente e 
o servidor, conforme ilustrado pela linha de tempo dada na Figura 5.6. 

A ideia é que as duas partes querem chegar a um acordo sobre um conjunto de parâmetros que, 
no caso da abertura de uma conexão TCP são os números de sequência iniciais que os dois lados 
planejam usar para seus respectivos fluxos de bytes. Em geral, os parâmetros poderiam ser quaisquer 
informações que cada lado queira que o outro saiba. Primeiro, o cliente (o participante ativo) envia um 
segmento ao servidor (o participante passivo) indicando o número de sequência inicial que planeja 


Para ser mais preciso, o estabelecimento da conexão pode ser simétrico, com os dois lados tentando abrir a conexão 
ao mesmo tempo, mas o caso comum é que um lado realize uma abertura ativa e o outro realize uma abertura passiva. 
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Participante ativo Participante passivo FIGURA 5.6 Linha de tempo para o algoritmo de three-way handshake 
(cliente) (servidor) (apresentação em três vias). 





usar (Flags=SYN, NúmeroSeq =x). O servidor então responde com um único segmento que confirma 
o número de sequência do cliente (Flags =ACK, Ack=x+ 1) e indica seu número de sequência inicial 
(Flags=SYN, NúmeroSeg=y). Ou seja, tanto os bits de SYN como os de ACK são marcados no campo 
Flags dessa segunda mensagem. Finalmente, o cliente responde com um terceiro segmento e confirma 
o número de sequência do servidor (Flags=ACK, Ack=y+ 1). O motivo para cada lado confirmar um 
número de sequência que é um a mais que aquele enviado é que o campo Confirmação na realidade 
identifica o “próximo número de sequência esperado”, implicitamente confirmando assim todos os 
números de sequência anteriores. Embora não seja mostrado nessa linha de tempo, um temporizador 
é programado para cada um dos dois primeiros segmentos, e se a resposta esperada não for recebida, 
o segmento é retransmitido. 

Você pode estar se perguntando por que o cliente e o servidor precisam trocar números de sequência 
iniciais um com o outro no momento do estabelecimento da conexão. Seria mais simples se cada lado 
simplesmente começasse em algum número de sequência “bem conhecido”, como 0. Na verdade, a 
especificação TCP requer que cada lado de uma conexão selecione um número de sequência inicial 
aleatoriamente. O motivo para isso é proteger contra duas ocorrências da mesma conexão reutilizando 
os mesmos números de sequência muito cedo - ou seja, enquanto ainda existe uma chance de que um 
segmento de uma ocorrência anterior de uma conexão possa interferir com uma ocorrência posterior 
da conexão. 


Diagrama de transição de estados 

O TCP é tão complexo que sua especificação inclui um diagrama de transição de estados. Uma cópia 
desse diagrama é mostrada na Figura 5.7. Esse diagrama mostra apenas os estados envolvidos na aber- 
tura de uma conexão (tudo acima de ESTABLISHED) e no fechamento de uma conexão (tudo abaixo 
de ESTABLISHED). Tudo o que acontece enquanto uma conexão está aberta — ou seja, a operação do 
algoritmo de janela deslizante — fica oculto no estado ESTABLISHED. 

O diagrama de transição de estados do TCP é razoavelmente fácil de entender. Cada círculo indica um 
estado em que uma extremidade de uma conexão TCP pode se encontrar. Todas as conexões começam 
no estado CLOSED. À medida que se prossegue com a conexão, a conexão se move de um estado para 
outro de acordo com os arcos. Cada arco é rotulado com um rótulo da forma evento/ação. Assim, se 
uma conexão está no estado LISTEN e um segmento SYN chega (ou seja, um segmento com o flag SYN 
marcado), a conexão faz uma transição para o estado SYN RCVD e toma a ação de responder com um 
segmento ACK+SYN. 

Observe que dois tipos de eventos disparam uma transição de estado: (1) um segmento chega do 
par (por exemplo, o evento no arco de LISTEN para SYN RCVD) ou (2) o processo da aplicação local 
chama uma operação no TCP (por exemplo, um evento de abertura ativa no arco de CLOSED para 
SYN SENT). Em outras palavras, o diagrama de transição de estados do TCP efetivamente define a 
semântica de sua interface de para e de sua interface de serviço, conforme definido na Seção 1.3.1. A 
sintaxe dessas duas interfaces é dada pelo formato do segmento (conforme ilustrado na Figura 5.4) 
e por alguma interface de programação de aplicação (como no exemplo dado na Seção 1.4.1), 
respectivamente. 
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FIGURA 5.7 Diagrama de transição de estados do TCP. 


Agora, vamos acompanhar as transições típicas feitas no diagrama da Figura 5.7. Lembre-se que, em 
cada extremidade da conexão, o TCP faz diferentes transições de um estado para outro. Ao abrir uma 
conexão, o servidor primeiro chama uma operação de abertura passiva no TCP que faz com que o TCP 
se mova para o estado LISTEN. Em algum momento posterior, o cliente realiza uma abertura ativa, que 
faz com que sua extremidade da conexão envie um segmento SYN para o servidor e vá para o estado 
SYN SENT. Quando o segmento SYN chega ao servidor, ele passa para o estado SYN RCVD e responde 
com um segmento SYN + ACK. A chegada desse segmento faz com que o cliente mude para o estado 
ESTABLISHED e envie um ACK de volta ao servidor. Quando esse ACK chega, o servidor finalmente 
passa para o estado ESTABLISHED. Em outras palavras, simplesmente acompanhamos o three-way 
handshake. 

Existem três coisas a observar sobre a metade referente ao estabelecimento de conexão do diagrama 
de transição de estados. Primeiro, se o ACK do cliente para o servidor for perdido, correspondendo à 
terceira mensagem do handshake de três vias, então a conexão ainda funciona corretamente. Isso porque 
o lado do cliente já está no estado ESTABLISHED, de modo que o processo de aplicação local pode 
começar a enviar dados à outra ponta. Cada um desses segmentos de dados terá o flag ACK marcado, 
e o valor correto no campo Confirmação, de modo que o servidor passará para o estado ESTABLISHED 
quando o primeiro segmento de dados chegar. Isso é realmente um ponto importante sobre o TCP - cada 
segmento informa qual número de sequência o transmissor está esperando ver em seguida, mesmo que 
este repita o mesmo número de sequência contido em um ou mais segmentos anteriores. 

A segunda coisa a observar sobre o diagrama de transição de estados é que existe uma transição 
estranha a partir do estado LISTEN sempre que o processo local invoca uma operação send no TCP 
Ou seja, é possível que um participante passivo identifique as duas extremidades da conexão (i.e., ele 
mesmo e o participante remoto que está disposto a conectar-se com ele) e depois mude de ideia sobre 
esperar pelo outro lado e, em vez disso, estabeleça a conexão ativamente. Pelo que sabemos, esse é um 
recurso do TCP do qual nenhum processo da aplicação realmente tira proveito. 
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Aúltima coisa a observar sobre o diagrama são os arcos que não são mostrados. Especificamente, a 
maior parte dos estados que envolvem o envio de um segmento ao outro lado também programa um 
temporizador que, ao expirar, faz com que o segmento seja reenviado se a resposta esperada não for 
recebida. Essas retransmissões não são representadas no diagrama de transição de estados. Se, depois 
de várias tentativas, a resposta esperada não chegar, o TCP desiste e retorna ao estado CLOSED. 

Voltando nossa atenção agora ao processo de terminar uma conexão, o mais importante a lembrar é 
que o processo da aplicação nos dois lados da conexão precisa fechar independentemente sua metade 
da conexão. Se apenas um lado fechar a conexão, então isso significa que ele não tem mais dados 
para enviar, mas ainda está disponível para receber dados do outro lado. Isso complica o diagrama 
de transição de estados porque é preciso considerar a possibilidade de que os dois lados invoquem a 
operação de fechamento ao mesmo tempo, além da possibilidade de que primeiro um lado invoque 
o fechamento e depois, em outro momento, o outro lado invoque o fechamento. Assim, em qualquer 
lado existem três combinações de transições que levam uma conexão do estado ESTABLISHED para o 
estado CLOSED: 


e Este lado fecha primeiro: ESTABLISHED = FIN WAIT 1 FIN WAIT 2 =STIME WAIT 5 CLOSED. 

e O outro lado fecha primeiro: ESTABLISHED — CLOSE WAIT — LAST ACK — CLOSED. 

e Os dois lados fecham ao mesmo tempo: ESTABLISHED > FIN WAIT 1 —> CLOSINGSTIME 
WAIT — CLOSED. 


Na realidade, há uma quarta sequência de transições, embora rara, que leva ao estado CLOSED; ela 
segue o arco de FIN WAIT 1 para TIME WATT. Deixamos como exercício para o leitor descobrir que 
combinação de circunstâncias leva a essa quarta possibilidade. 

O principal a reconhecer sobre o encerramento da conexão é que uma conexão no estado TIME WAIT 
não pode passar para o estado CLOSED até que tenha esperado por duas vezes a quantidade máxima de 
tempo que um datagrama IP poderia sobreviver na Internet (ou seja, 120 segundos). O motivo para isso 
é que, embora o lado local da conexão tenha enviado um ACK em resposta ao segmento FIN do outro 
lado, ele não sabe que o ACK foi entregue com sucesso. Por conseguinte, o outro lado poderia transmitir 
seu segmento FIN e esse segundo segmento FIN poderia ser atrasado na rede. Se a conexão pudesse 
mover-se diretamente para o estado CLOSED, então outro par de processos da aplicação poderia surgir e 
abrir a mesma conexão (ou seja, usar o mesmo par de números de porta), e o segmento FIN atrasado da 
ocorrência anterior da conexão imediatamente iniciaria o término desta nova ocorrência da conexão. 


5.2.4 Janela deslizante revisada 


Agora, estamos prontos para discutir sobre a variante do algoritmo de janela deslizante usada pelo TCP 
que serve a várias finalidades: (1) ela garante a entrega confiável dos dados, (2) ela garante que os dados 
são entregues na ordem e (3) ela impõe o controle de fluxo entre o emissor e o receptor. O uso do TCP 
para o algoritmo de janela deslizante é o mesmo daquele que vimos na Seção 2.5.2 no caso das duas 
primeiras dessas três funções. Onde o TCP difere do algoritmo anterior é que ele também inclui a função 
de controle de fluxo. Em particular, em vez de ter uma janela deslizante de tamanho fixo, o receptor 
anuncia um tamanho de janela para o transmissor. Isso é feito usando o campo JanelaAnunciada no 
cabeçalho TCP O transmissor, então, é limitado a não ter mais do que um valor de JanelaAnunciada 
bytes de dados não confirmados em determinado momento. O receptor seleciona um valor adequado 
para JanelaAnunciada com base na quantidade de memória alocada à conexão com a finalidade de 
manter dados em buffer. A ideia é evitar que o emissor inunde o buffer do receptor. Discutiremos me- 
lhor sobre isso a seguir. 


Entrega confiável e ordenada 

Para ver como os lados emissor e receptor do TCP interagem um com o outro para implementar a en- 
trega confiável e ordenada, considere a situação ilustrada na Figura 5.8. O TCP no lado emissor mantém 
um buffer de envio. Esse buffer é usado para armazenar dados que foram enviados, mas ainda não 
confirmados, além dos dados que foram escritos pela aplicação emissora, mas não transmitidos. No 
lado receptor, o TCP mantém um buffer de recepção. Esse buffer mantém dados que chegam fora de 
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FIGURA 5.8 Relação entre o buffer de envio (a) e o buffer de recepção (b) do TCP. 


ordem, além de dados que estão na ordem correta (ou seja, não existem bytes faltando anteriormente 
no fluxo), mas que o processo da aplicação ainda não teve a chance de ler. 

Para tornar a discussão a seguir mais simples de acompanhar, ignoramos inicialmente o fato de 
que tanto os buffers como os números de sequência têm algum tamanho finito e, portanto, em certo 
momento serão reiniciados ciclicamente. Além disso, não distinguimos entre um ponteiro em um buffer 
onde um byte de dados em particular é armazenado e o número de sequência para esse byte. 

Examinando primeiro o lado transmissor, três ponteiros são mantidos no buffer de emissão, 
cada um com um significado óbvio, ÚltimoByteConfirmado, ÚltimoByteEnviado, e ÚltimoByteEscrito. 
Claramente, 


ÚltimoByteConfirmado < ÚltimoByteEnviado 


pois o receptor não pode ter confirmado um byte que ainda não foi enviado, e 


ÚltimoByteEnviado < ÚltimoByteEscrito 


pois o TCP não pode enviar um byte que o processo da aplicação ainda não escreveu. Além disso, 
observe que nenhum dos bytes à esquerda de ÚltimoByteConfirmado precisa ser salvo no buffer, pois 
eles já foram confirmados, e nenhum dos bytes à direita de ÚltimoByteEscrito precisa ser mantido em 
buffer, pois ainda não foram gerados. 

Um conjunto de ponteiros (números de sequência) semelhante é mantido no lado receptor: Último- 
ByteEscrito, PróxByteEsperado e ÚltimoByteRecebido. Contudo, as desigualdades são um pouco menos 
intuitivas, em virtude do problema da entrega fora de ordem. A primeira relação 


ÚltimoByteEscrito < PróxByteEsperado 


é verdadeira porque um byte não pode ser lido pela aplicação até que seja recebido e todos os bytes 
anteriores também tenham sido recebidos. PróxByteEsperado aponta para o byte imediatamente após 
o último byte que satisfaz esse critério. Segundo, 


PróxByteEsperado < ÚltimoByteRecebido + 1 


pois, se os dados chegarem na ordem, PróxByteEsperado aponta para o byte após ÚltimoByteRece- 
bido, enquanto se os dados chegarem fora de ordem, então PróxByteEsperado aponta para o início da 
primeira lacuna nos dados, como na Figura 5.8. Observe que os bytes à esquerda de ÚltimoByteEscrito 
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não precisam ser mantidos em buffer, pois já foram lidos pelo processo da aplicação local, e os bytes à 

direita de UltimoByteRecebido não precisam ser mantidos em buffer, pois ainda não chegaram. 


Controle de fluxo 

A maior parte da discussão anterior é semelhante à que encontramos na Seção 2.5.2; a única diferença 
real é que, desta vez, discutimos mais longamente o fato de que os processos das aplicações de envio 
e de recepção estão enchendo e esvaziando seu buffer local, respectivamente. (A discussão anterior 
apenas mencionou o fato de que os dados provenientes da aplicação no nó emissor estavam enchendo 
o buffer de emissão e os dados sendo entregues à aplicação no nó receptor estavam esvaziando o buffer 
de recepção.) 

Você deve ter certeza de que entendeu bem isso antes de prosseguir, pois agora chegamos ao ponto 
em que os dois algoritmos diferem de modo mais significativo. A seguir, introduzimos novamente o 
fato de que os dois buffers têm algum tamanho finito, indicado por BufferEnvioMáx e BufferRecMáx, 
embora não nos preocupemos com os detalhes de como eles são implementados. Em outras palavras, 
só estamos interessados no número de bytes sendo mantidos em buffer, e não em onde esses bytes são 
realmente armazenados. 

Lembre-se que, em um protocolo de janela deslizante, o tamanho da janela define a quantidade de 
dados que podem ser enviados sem esperar por confirmação do receptor. Assim, o receptor limita o 
emissor anunciando uma janela que não seja maior do que a quantidade de dados que ele pode manter 
em buffer. Observe que o TCP no lado receptor precisa manter 


ÚltimoByteRecebido — ÚltimoByteEscrito < BufferRecMáx 


para evitar estourar seu buffer. Portanto, ele anuncia um tamanho de janela de 


JanelaAnunciada = BufferRecMáx — ((PróxByteEsperado — 1) — ÚltimoByteEscrito) 


que representa a quantidade de espaço livre restante em seu buffer. À medida que os dados chegam, 
o receptor os confirma contanto que todos os bytes anteriores também tenham chegado. Além disso, 
ÚltimoByteRecebido se move para a direita (é incrementado), significando que a janela anunciada 
potencialmente se encolhe. Se ela encolhe ou não, isso depende da velocidade com que o processo da 
aplicação está consumindo dados. Se o processo local estiver lendo dados com a mesma velocidade 
em que eles chegam (fazendo com que ÚltimoByteEscrito seja incrementado na mesma velocidade de 
ÚltimoByteRecebido), então a janela anunciada permanece aberta (ou seja, JanelaAnunciada = Buffer- 
RecMáx). Se, no entanto, o processo receptor ficar para trás, talvez porque realiza uma operação muito 
custosa computacionalmente sobre cada byte de dados que lê, então a janela anunciada ficar menor 
com cada segmento recebido, até que por fim chegue a 0. 

O TCP no lado emissor precisa então conformar-se com a janela anunciada que recebe do receptor. 
Isso significa que, a qualquer momento, ele deve garantir que 


ÚltimoByteEnviado — ÚltimoByteConfirmado < JanelaAnunciada 


Em outras palavras, o emissor calcula uma janela efetiva que limita quantos dados ele pode enviar: 


JanelaEfetiva = JanelaAnunciada — (ÚltimoByteEnviado — ÚltimoByteConfirmado) 


Claramente, JanelaEfetiva precisa ser maior do que 0 antes que a origem possa enviar mais dados. 
Portanto, é possível que um segmento chegue confirmando x bytes, permitindo assim que o transmissor 
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incremente ÚltimoByteConfirmado em x, mas como o processo receptor não estava lendo dado algum, 
a janela anunciada agora é x bytes menor do que na vez anterior. Nessa situação, o transmissor seria 
capaz de liberar espaço em buffer, mas não de enviar mais dados. 

Ao mesmo tempo em que isso está acontecendo, o lado emissor também precisa garantir que o 
processo da aplicação local não estoure o buffer de envio — ou seja, que 


ÚltimoByteEscrito — ÚltimoByteConfirmado < BufferEnvioMáx 


Se o processo emissor tentar escrever y bytes no TCP mas 


(ÚltimoByteEscrito — ÚltimoByteConfirmado) + y > BufferEnvioMáx 


então o TCP bloqueia o processo emissor e não permite que ele gere mais dados. 

Agora é possível entender como um processo receptor lento, em certo momento, interrompe um 
processo emissor rápido. Primeiro, o buffer de recepção se enche, o que significa que a janela anunciada 
se reduz a 0. A janela anunciada de 0 significa que o lado transmissor não pode transmitir dado algum, 
embora dados que ele tenha enviado anteriormente tenham sido confirmados com sucesso. Por fim, 
não poder transmitir quaisquer dados significa que o buffer de envio fica cheio, o que faz com que o 
TCP bloqueie o processo emissor. Assim que o processo receptor começar a ler dados novamente, o 
TCP no lado receptor é capaz de abrir sua janela novamente, o que permite que o TCP do lado emissor 
transmita os dados do seu buffer. Quando esses dados forem confirmados, ÚltimoByteConfirmado é 
incrementado, o espaço em buffer mantendo esses dados confirmados é liberado e o processo emissor 
é desbloqueado e tem permissão para prosseguir com o envio. 

Há somente um detalhe que precisa ser resolvido - como o lado emissor sabe que a janela anunciada 
não é mais 0? Como já dissemos, o TCP sempre envia um segmento em resposta a um segmento de dados 
recebido, e essa resposta contém os valores mais recentes para os campos Confirmação e JanelaAnunciada, 
mesmo que esses valores não tenham mudado desde a última vez em que foram enviados. O problema é 
esse. Quando o lado receptor tiver anunciado um tamanho de janela igual a 0, o transmissor não tem per- 
missão para enviar mais dados, o que significa que ele não tem como descobrir que a janela anunciada não 
é mais O em algum momento no futuro. O TCP no lado receptor não envia espontaneamente segmentos 
que não contenham dados; ele só os envia em resposta a um segmento de dados que chega. 

O TCP lida com essa situação da seguinte forma. Sempre que o outro lado anuncia um tamanho 
de janela igual a 0, o lado emissor persiste em ficar enviando um segmento com 1 byte de dados com 
alguma frequência. Ele sabe que esses dados provavelmente não serão aceitos, mas tenta de qualquer 
forma, pois cada um desses segmentos de 1 byte dispara uma resposta que contém a janela anunciada 
atual. Em algum momento, um desses segmentos de sondagem de 1 byte dispara uma resposta que 
informa uma janela anunciada diferente de zero. 


Observe que o motivo para o lado transmissor enviar esse segmento de sondagem periodicamente é que 
o TCP foi projetado para tornar o lado receptor o mais simples possível - ele simplesmente responde aos 
segmentos do transmissor, e nunca inicia qualquer atividade por conta própria. Esse é um exemplo de uma 


regra de projeto de protocolo bem reconhecida (embora não aplicada universalmente) que, por falta de um 
nome melhor, chamamos de regra do transmissor inteligente/receptor burro. Lembre-se que vimos outro 
exemplo dessa regra quando discutimos sobre o uso de NAKs na Seção 2.5.2. 





Protegendo-se contra o reinício cíclico 
Esta subseção e a próxima consideram o tamanho dos campos NúmeroSeq e JanelaAnunciada e as 
implicações de seus tamanhos sobre a eficácia e o desempenho do TCP O campo NúmeroSeg do TCP 





Capítulo 5 * Protocolos fim a fim 253 


ELSEVIER 


Tabela 5.1 Tempo até que o espaço dos números de sequência de 32 bits seja reiniciado 





Largura de banda Tempo até o reinício 
T1 (1,5 Mbps) 6,4 horas 

Ethernet (10 Mbps) 57 minutos 

T3 (45 Mbps) 13 minutos 

Fast Ethernet (100 Mbps) 6 minutos 

OC-3 (155 Mbps) 4 minutos 

OC-12 (622 Mbps) 55 segundos 

OC-48 (2,5 Gbps) 14 segundos 


tem 32 bits de extensão, e seu campo JanelaAnunciada tem 16 bits, significando que o TCP satisfaz 
facilmente o requisito do algoritmo de janela deslizante, de que o espaço dos números de sequência 
seja o dobro do tamanho da janela: 23? >> 2 x 216, Porém, esse requisito não é a coisa mais interessante 
sobre esses dois campos. Vamos considerar cada um por vez. 

A relevância do espaço de números de sequência de 32 bits é que o número de sequência usado 
em determinada conexão poderia ser reiniciado ciclicamente após atingir o valor máximo — um byte 
no número de sequência x poderia ser enviado em determinado momento e depois um segundo byte 
com o mesmo número de sequência x poderia ser enviado. Mais uma vez, assumimos que os pacotes 
não podem sobreviver na Internet por mais tempo do que o MSL recomendado. Assim, atualmente 
precisamos garantir que o número de sequência não seja reiniciado dentro de um período de tempo 
de 120 segundos. Se isso acontece ou não, depende da velocidade com que os dados podem ser trans- 
mitidos pela Internet — ou seja, a velocidade com que o espaço dos números de sequência de 32 bits 
pode ser consumido. (A discussão considera que estamos tentando consumir o espaço dos números de 
sequência o mais rápido possível, mas logicamente faremos isso se estivermos realizando nosso trabalho 
de manter o tubo cheio.) A Tabela 5.1 mostra quanto tempo é necessário para o número de sequência 
ser reiniciado em redes com diversas larguras de banda. 

Como você pode ver, o espaço dos números de sequência de 32 bits é adequado para a maioria 
das situações encontradas nas redes de hoje, mas como existem enlaces OC-192 no backbone da 
Internet, e como a maioria dos servidores agora vem com interfaces Gigabit Ethernet (ou 10 Gbps), 
estamos nos aproximando do ponto onde 32 bits é muito pouco espaço. Felizmente, a IETF já preparou 
uma extensão para o TCP que efetivamente estende o espaço do número de sequência para proteger 
contra números de sequência que se repetem. Esta e outras extensões relacionadas são descritas na 
Seção 5.2.8. 


Mantendo o tubo cheio 

A relevância do campo JanelaAnunciada de 16 bits é que ele precisa ser grande o suficiente para per- 
mitir que o emissor mantenha o tubo cheio. Logicamente, o receptor está livre para não abrir a janela 
até um tamanho tão grande quanto o campo JanelaAnunciada permite; estamos interessados na si- 
tuação em que o receptor tem espaço de buffer suficiente para lidar com tantos dados quanto a maior 
JanelaAnunciada possível permite. 

Nesse caso, não é apenas a largura de banda da rede, mas o produto atraso X largura de banda que 
dita o tamanho que o campo JanelaAnunciada precisa ter — a janela precisa estar aberta o suficiente para 
permitir uma quantidade de dados equivalente a o produto atraso x largura de banda seja transmitida. 
Considerando um RTT de 100 ms (um número típico para uma conexão cruzando os Estados Unidos), 
a Tabela 5.2 oferece um produto atraso X largura de banda para várias tecnologias de rede. 

Como você pode ver, o campo JanelaAnunciada do TCP está ainda em pior forma do que seu campo 
NúmeroSeq - ele não é grande o suficiente para lidar sequer com uma conexão continental T3 atraves- 
sando os Estados Unidos, pois um campo de 16 bits nos permite anunciar uma janela de apenas 64 KB. 
A mesma extensão do TCP mencionada anteriormente (ver Seção 5.2.8) oferece um mecanismo para 
aumentar efetivamente o tamanho da janela anunciada. 
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Tabela 5.2 Tamanho de janela exigido para um RTT de 100 ms 





Largura de banda Produto atraso x largura de banda 
T1 (1,5 Mbps) 18 KB 

Ethernet (10 Mbps) 122 KB 

T3 (45 Mbps) 549 KB 

Fast Ethernet (100 Mbps) 1,2 MB 

OC-3 (155 Mbps) 1,8 MB 

OC-12 (622 Mbps) 7,4 MB 

OC-48 (2,5 Gbps) 29,6 MB 


5.2.5 Iniciando a transmissão 


Em seguida, consideramos uma questão surpreendentemente sutil: como o TCP decide transmitir um 
segmento. Conforme descrevemos, o TCP admite uma abstração de fluxo de bytes; ou seja, os programas 
de aplicação escrevem bytes no fluxo e fica a cargo do TCP decidir se ele tem bytes suficientes para enviar 
um segmento. Que fatores controlam essa decisão? 

Se ignorarmos a possibilidade de controle de fluxo — ou seja, se considerarmos que a janela está com- 
pletamente aberta, como aconteceria quando uma conexão é iniciada —, então o TCP tem três mecanismos 
para disparar a transmissão de um segmento. Primeiro, o TCP mantém uma variável, comumente chamada 
tamanho máximo de segmento (MSS — Maximum Segment Size) e envia um segmento assim que ele tiver 
coletado MSS bytes do processo emissor. O valor de MSS normalmente é definido com o tamanho do 
maior segmento que o TCP pode enviar sem fazer com que o IP local seja fragmentado. Ou seja, o valor 
do MSS corresponde à unidade máxima de transmissão (MTU) da rede à qual o dispositivo está conectado 
diretamente, menos o tamanho dos cabeçalhos TCP e IP A segunda coisa que dispara a transmissão de 
segmentos no TCP é quando o processo emissor lhe pede explicitamente para fazer isso. Especificamente, 
o TCP admite uma operação de push, e o processo emissor chama essa operação para efetivamente 
esvaziar o buffer de bytes não enviados. O último fator que leva à transmissão de um segmento é quando 
um temporizador dispara; o segmento resultante contém tantos bytes quantos existam atualmente em 
buffer para transmissão. Porém, como veremos em breve, esse “temporizador” não é exatamente o que 
você espera. 


Síndrome da janela boba 

Naturalmente, não podemos simplesmente ignorar o controle de fluxo, que desempenha um papel 
óbvio para limitar o emissor. Se o emissor tiver MSS bytes de dados para enviar e a janela for aberta pelo 
menos por essa quantidade, então o emissor transmite um segmento completo. Suponha, porém, que 
o emissor esteja acumulando bytes para enviar, mas a janela esteja atualmente fechada. Agora suponha 
que um ACK chegue para efetivamente abrir a janela o suficiente para que o emissor transmita, digamos, 
MSS/2 bytes. O emissor deverá transmitir um segmento semicheio ou esperar que a janela se abra por 
um MSS completo? A especificação original não tratava desse ponto, e as primeiras implementações 
do TCP decidiam ir em frente e transmitir um segmento semicheio. Afinal, não há como saber quanto 
tempo demorará até que a janela se abra mais. 

Acontece que a estratégia de tirar proveito agressivamente de qualquer janela disponível leva a uma 
situação atualmente conhecida como síndrome da janela boba (silly window syndrome). A Figura 5.9 
ajuda a visualizar o que acontece. Se você pensar em um fluxo TCP como uma esteira transportadora 
com recipientes (segmentos de dados) “cheios” indo em uma direção, e recipientes vazios (ACKs) 
indo na direção oposta, então os segmentos com tamanho MSS correspondem a recipientes grandes, 
e segmentos de 1 byte correspondem a recipientes muito pequenos. Enquanto o transmissor estiver 
enviando segmentos com tamanho MSS e o receptor confirmar com ACKs pelo menos um MSS de dados 
por vez, tudo funcionará bem (Figura 5.9(a)). Mas, e se o receptor reduzir a janela, de modo que em 
algum momento o emissor não possa enviar um MSS completo de dados? Se o emissor agressivamente 
preencher um recipiente com menos de um MSS assim que o ACK chegar, então o receptor confirmará 
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FIGURA 5.9 Síndrome da janela boba. (a) Enquanto o emissor envia segmentos com tamanho igual ao MSS e o receptor confirma 
um MSS de cada vez, o sistema funciona bem. (b) Assim que o emissor envia menos de um MSS, ou o receptor confirma menos 
de um MSS, um pequeno “recipiente” entra no sistema e continua a circular. 


esse número menor de bytes e, portanto, o recipiente pequeno introduzido no sistema permanece 
no sistema indefinidamente. Ou seja, ele é imediatamente preenchido e esvaziado em cada terminal 
e nunca é agrupado aos recipientes adjacentes para criar recipientes maiores, como na Figura 5.9(b). 
Esse cenário foi descoberto quando as primeiras implementações do TCP regularmente se encontravam 
enchendo a rede com segmentos minúsculos. 

Observe que a síndrome da janela boba é um problema somente quando o emissor transmite 
um segmento pequeno ou o receptor abre a janela por uma pequena quantidade. Se nenhum desses 
acontecer, então o pequeno recipiente nunca é introduzido no fluxo. Não é possível impedir o envio de 
segmentos pequenos; por exemplo, a aplicação poderia realizar um push após enviar um único byte. 
Porém, é possível evitar que o receptor introduza um recipiente pequeno (ou seja, uma janela aberta 
pequena). A regra é que, depois de anunciar uma janela zero, o receptor deve esperar por um espaço 
igual a um MSS antes de anunciar uma janela aberta. 

Como não podemos eliminar a possibilidade de um recipiente pequeno ser introduzido no fluxo, 
também precisamos de mecanismos para agrupar tais recipientes. O receptor pode fazer isso atrasando 
ACKs - enviando um ACK combinado em vez de vários menores —, mas isso é apenas uma solução 
parcial, pois o receptor não tem como saber por quanto tempo é seguro esperar até que outro seg- 
mento chegue ou que a aplicação leia mais dados (abrindo, assim, a janela). A solução definitiva está 
no emissor, o que nos leva de volta à nossa questão inicial: quando o TCP emissor decide transmitir 
um segmento? 


Algoritmo de Nagle 

Retornando ao TCP emissor, se houver dados para enviar, mas a janela for aberta por menos do que 
MSS, então podemos querer esperar por algum período de tempo antes de enviar os dados disponíveis, 
mas a questão é: por quanto tempo? Se esperarmos muito, então atrapalhamos aplicações interativas 
como Telnet. Se não esperarmos por tempo suficiente, então corremos o risco de enviar um punhado 
de pacotes pequenos e cairmos na síndrome da janela boba. A resposta é introduzir um temporizador 
e transmitir quando ele expirar. 

Embora pudéssemos usar um temporizador baseado em relógio — por exemplo, um que dispare a 
cada 100 ms -, Nagle introduziu uma solução elegante de autorregulação. A ideia é que, enquanto o 
TCP tiver qualquer dado em trânsito, o emissor em algum momento receberá um ACK. Esse ACK pode 
ser tratado como um disparo de temporizador, iniciando a transmissão de mais dados. O algoritmo 
de Nagle oferece uma regra simples, unificada, para decidir quando transmitir: 
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Quando a aplicação produzir dados para enviar 
se ambos dados disponíveis e janela > MSS 
envia um segmento completo 
senão 
se existem dados não confirmados na rede 
coloca novos dados no buffer até que um ACK chegue 
senão 
envia todos os novos dados agora 


Em outras palavras, é sempre válido enviar um segmento completo se a janela permitir. Também não há 
problema em enviar imediatamente uma pequena quantidade de dados se atualmente não houver seg- 
mentos em trânsito, mas, se houver algo a caminho do receptor, o emissor precisa esperar um ACK antes de 
transmitir o próximo segmento. Assim, uma aplicação interativa como Telnet, que escreve continuamente 
um byte de cada vez, enviará dados em uma velocidade de um segmento por RTT. Alguns segmentos terão 
um único byte, enquanto outros terão tantos bytes quantos o usuário for capaz de digitar em um tempo 
de ida e volta. Como algumas aplicações não podem arcar com um atraso para cada escrita feita a uma 
conexão TCP a interface de socket permite que a aplicação desative o algoritmo de Nagle definindo a opção 
TCP NODELAY. A definição dessa opção significa que os dados são transmitidos o mais cedo possível. 


5.2.6 Retransmissão adaptativa 


Como o TCP garante a entrega confiável de dados, ele retransmite cada segmento se um ACK não for 
recebido em certo período de tempo. O TCP define o valor desse tempo limite de expiração como uma 
função do RTT que espera entre as duas extremidades da conexão. Infelizmente, dado o intervalo de 
RTTs possíveis entre qualquer par de hosts na Internet, além da variação no RTT entre os mesmos dois 
hosts com o tempo, a escolha de um valor apropriado do tempo limite de expiração não é tão fácil. Para 
resolver esse problema, o TCP usa um mecanismo de retransmissão adaptativa. Agora, vamos descrever 
esse mecanismo e como ele evoluiu com o tempo, enquanto a comunidade da Internet ganhou mais 
experiência com o uso do TCP 


Algoritmo original 

Começamos com um algoritmo simples para calcular um valor de tempo limite de expiração entre um 
par de hosts. Esse é o algoritmo que foi descrito originalmente na especificação do TCP — e a descrição 
a seguir o apresenta nesses termos —, mas poderia ser usado por qualquer protocolo fim a fim. 

A ideia é manter uma média móvel do RTT e depois calcular o tempo limite de expiração como uma 
função desse RTT. Especificamente, toda vez que o TCP envia um segmento de dados, ele registra a hora 
de envio. Quando um ACK para esse segmento chega, o TCP verifica a hora novamente, e depois calcula 
a diferença entre essas duas horas como um RT TAmostra. O TCP então, calcula um RTTEstimado como 
uma média ponderada entre a estimativa anterior e essa nova amostra. Ou seja, 


RTTEstimado = a x RTTEstimado + (1 — a) x RTTAmostra 


O parâmetro é selecionado para suavizar o RTTEstimado. Um a pequeno leva em consideração as 
mudanças no RTT, mas talvez seja excessivamente influenciado por flutuações temporárias. Por outro 
lado, um « grande é mais estável, mas talvez não rápido o suficiente para adaptar-se a mudanças reais. 
A especificação do TCP original recomendava um valor entre 0,8 e 0,9. O TCP então usa RTTEstimado 
para calcular o tempo limite de expiração de uma maneira um tanto conservadora: 


TempoExpiração = 2 x RTTEstimado 


Algoritmo de Karn/Partridge 
Depois de vários anos sendo usado na Internet, uma falha de certa forma óbvia foi descoberta neste 
algoritmo simples. O problema é que um ACK não confirma de fato uma transmissão; na realidade, ele 
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Emissor Receptor Emissor Receptor FIGURA 5.10 Associando o ACK (a) com a 
transmissão original e (b) com a retransmissão. 
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confirma o recebimento dos dados. Em outras palavras, sempre que um segmento é retransmitido e 
depois um ACK chega ao transmissor, é impossível determinar se esse ACK deveria ser associado à pri- 
meira ou à segunda transmissão do segmento para fins de medição de RTTAmostra. É preciso saber a qual 
transmissão associá-lo a fim de calcular um RT TAmostra preciso. Conforme ilustramos na Figura 5.10, se 
você considerar que o ACK refere-se à transmissão original, mas na realidade referir-se à segunda, então 
o valor de RT TAmostra é muito grande (a); se você considerar que o ACK refere-se à segunda transmissão, 
mas na realidade ele referir-se à primeira, então o valor RTTAmostra é muito pequeno (b). 

A solução, que foi proposta em 1987, é incrivelmente simples. Sempre que o TCP retransmite um 
segmento, ele interrompe a amostragem do RTT; ele só mede o RTTAmostra para segmentos que foram 
enviados apenas uma vez. Essa solução é conhecida como algoritmo de Karn/Partridge, os nomes de 
seus inventores. A melhoria proposta também inclui uma segunda pequena mudança no mecanismo 
de tempo limite de expiração do TCP. Toda vez que o TCP retransmite, ele define o próximo tem- 
po limite de expiração como o dobro do último tempo limite de expiração, em vez de baseá-los 
no último RTTEstimado. Ou seja, Karn e Partridge propuseram que o TCP usasse o recuo exponencial, 
semelhante ao que as redes Ethernet fazem. A motivação para usar o recuo exponencial é simples: o 
congestionamento é a causa mais provável de segmentos perdidos, significando que o TCP de origem 
não deverá reagir muito agressivamente à expiração do tempo limite. Na verdade, quanto mais vezes a 
conexão atingir o tempo limite de expiração, mais cuidadosa a origem deverá se tornar. Veremos essa 
ideia novamente, incorporada em um mecanismo muito mais sofisticado, no Capítulo 6. 


Algoritmo de Jacobson/Karels 

O algoritmo de Karn/Partridge foi introduzido em uma época em que a Internet estava sofrendo de 
altos níveis de congestionamento de rede. Sua técnica foi projetada para resolver algumas das causas 
desse congestionamento, mas, embora sendo uma melhoria, o congestionamento não foi eliminado. No 
ano seguinte (1988), dois outros pesquisadores — Jacobson e Karels — propuseram uma mudança mais 
drástica no TCP para combater o congestionamento. Uma descrição mais detalhada dessa mudança 
proposta é descrita no Capítulo 6. Aqui, focalizamos o aspecto dessa proposta relacionado à decisão de 
quando o temporizador deve expirar e um segmento deve ser retransmitido. 

A propósito, devemos deixar claro como o mecanismo de expiração do tempo limite está relacio- 
nado ao congestionamento — se o tempo limite de expiração for muito curto, você poderá retrans- 
mitir um segmento desnecessariamente, o que só aumenta a carga na rede. Conforme veremos 
no Capítulo 6, o outro motivo pelo qual precisamos de um valor de tempo limite de expiração preciso 
é que uma expiração do tempo limite implica em congestionamento, que dispara um mecanismo 
de controle de congestionamento. Por fim, observe que não existe nada sobre o cálculo do tempo 
limite de expiração de Jacobson/Karels que seja específico do TCP Ele poderia ser usado por qualquer 
protocolo fim a fim. 

O problema principal com o cálculo original é que ele não leva em consideração a variabilidade dos 
RTTs da amostra. Intuitivamente, se a variação entre as amostras for pequena, então o RTTEstimado pode 
ser mais confiável e não haverá motivo para multiplicar essa estimativa por 2 para calcular o tempo limite 
de expiração. Por outro lado, uma variabilidade grande nas amostras sugere que o valor do tempo limite de 
expiração não deve estar tão próximo do RTTEstimado. 
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Na nova técnica, o emissor mede um novo RTTAmostra como antes. Depois, ele desdobra essa nova 
amostra no cálculo do tempo limite de expiração da seguinte forma: 


Diferença = RTTAmostra — RT TEstimado 
RTTEstimado = RTTEstimado + (ôx Diferença) 


Desvio = Desvio + ó (IDiferençal — Desvio) 


onde ô é uma fração entre 0 e 1. Ou seja, calculamos tanto o RTT médio quanto a variação dessa 
média. 

O TCP então calcula o valor do tempo limite de expiração como uma função de RTTEstimado e 
Desvio da seguinte forma: 


TempoExpiração = u x RTTEstimado + à x Desvio 


onde, com base na experiência, u normalmente é definido como 1 e q é definido como 4. Assim, 
quando a variabilidade é pequena, TempoExpiração fica próximo de RTTEstimado; uma variabilidade 
grande faz com que o termo relativo ao Desvio domine o cálculo. 


Implementação 

Existem dois itens a serem observados com relação à implementação de expiração do tempo limite no 
TCP O primeiro é que é possível implementar o cálculo para RTTEstimado e Desvio sem usar aritmética 
de ponto flutuante. Em vez disso, o cálculo todo é dimensionado para 2”, com ô selecionado como 1/2”. 
Isso nos permite realizar o cálculo usando aritmética de inteiros, implementando a multiplicação e a 
divisão usando deslocamentos e alcançando um desempenho mais alto. O cálculo resultante é dado 
pelo fragmento de código a seguir, onde n=3 (ou seja, ô=1/8). Observe que RTTEstimado e Desvio 
são armazenados em suas formas expandidas, enquanto o valor de RTTAmostra no início do código e 
TempoExpiração no final são valores reais, não expandidos. Se você achar o código difícil de acompa- 
nhar, pode tentar encaixar alguns números reais e verificar se os resultados são iguais aos das equações 
mostradas anteriormente. 


{ 

RTTAmostra -= (RTTEstimado >> 3); 

RTTEstimado += RTTAmostra; 

se (RTTAmostra < 0) 

RTTAmostra = - RTTAmostra; 

RTTAmostra -= (Desvio >> 3); 

Desvio += RTTAmostra; 

TempoExpiração = (RTTEstimado >> 3) + (Desvio >> 1); 
} 


O segundo ponto a observar é que o algoritmo de Jacobson/Karels é tão bom quanto permitido 
pelo relógio utilizado para obter a hora atual. Em uma implementação típica do Unix naquela época, a 
granularidade do relógio podia chegar a 500 ms, o que é significativamente maior do que o RTT médio 
para atravessar os EUA, algo entre 100 e 200 ms. Para piorar as coisas ainda mais, a implementação 
Unix do TOP só verificava se uma expiração do tempo limite devia acontecer toda vez que esse relógio 
de 500 ms se movesse, e ele só capturava uma amostra do tempo de ida e volta uma vez por RTT. A 
combinação desses dois fatores frequentemente podia significar que uma expiração do tempo limite 
ocorria 1 segundo depois que o segmento fosse transmitido. Mais uma vez, as extensões do TCP incluem 
um mecanismo que torna esse cálculo de RTT um pouco mais preciso. 

Todos os algoritmos de retransmissão que discutimos são baseados na expiração do tempo limite 
de confirmações, o que indica que um segmento provavelmente foi perdido. Observe que uma ex- 
piração do tempo limite, porém, não diz ao transmissor se quaisquer segmentos que ele enviou após o 
segmento perdido foram recebidos com sucesso. Isso porque as confirmações do TCP são cumulativas; 
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elas identificam apenas o último segmento que foi recebido sem quaisquer lacunas anteriores. O rece- 
bimento dos segmentos que aparecem após uma lacuna cresce em frequência à medida que redes mais 
rápidas levam a janelas maiores. Se ACKs também informassem ao emissor quais segmentos seguintes 
foram recebidos, caso haja algum, então o emissor poderia agir de forma mais inteligente sobre quais 
segmentos ele retransmite, chegar a conclusões melhores sobre o estado do congestionamento e fazer 
estimativas de RTT melhores. Uma extensão do TCP que dá suporte a isso é descrita na Seção 5.2.8. 


5.2.7 Fronteiras de registro 


Como TCP é um protocolo de fluxo de bytes, o número de bytes escritos pelo emissor não é neces- 
sariamente o mesmo número de bytes lidos pelo receptor. Por exemplo, a aplicação poderia escrever 8 
bytes, depois 2 bytes, depois 20 bytes em uma conexão TCP enquanto, no lado receptor, a aplicação lê 
5 bytes de cada vez dentro de um laço que se repete seis vezes. O TCP não insere fronteiras de registro 
entre o 8° e o 9º byte, nem entre o 10º e o 11º byte. Isso difere de um protocolo orientado a mensagens, 
como o UDP em que a mensagem enviada tem exatamente o mesmo tamanho da mensagem que é 
recebida. 

Embora o TCP seja um protocolo de fluxo de bytes, ele possui dois recursos diferentes que podem 
ser usados pelo emissor para inserir fronteiras de registro nesse fluxo de bytes, informando assim ao 
receptor como dividir o fluxo de bytes em registros. (Ser capaz de marcar fronteiras de registro é útil, por 
exemplo, em muitas aplicações de banco de dados.) Esses dois recursos foram incluídos originalmente 
no TCP por motivos completamente diferentes; eles só vieram a ser usados para esta finalidade com o 
passar do tempo. 

O primeiro mecanismo é o recurso de dados urgentes, conforme implementado pelo flag URG e pelo 
campo PtrUrg no cabeçalho TCP Originalmente, o mecanismo de dados urgentes foi projetado para 
permitir que a aplicação emissora enviasse dados fora da banda ao seu par. “Fora da banda” significa 
dados que estão separados do fluxo normal dos dados (por exemplo, um comando para interromper 
uma operação já a caminho). Esses dados fora da banda eram identificados no segmento por meio do 
campo PtrUrg e deveriam ser entregues ao processo receptor assim que chegassem, mesmo que isso 
significasse entregá-los antes dos dados com um número de sequência menor. Com o tempo, porém, 
esse recurso deixou de ser usado, de modo que, em vez de significar dados “urgentes”, ele passou a ser 
usado para significar dados “especiais”, como um marcador de registro. Esse uso se desenvolveu porque, 
como na operação push, o TCP no lado receptor precisa informar à aplicação que “dados urgentes” 
chegaram. Ou seja, os dados urgentes em si não são importantes. É o fato de que o processo emissor 
pode efetivamente enviar um sinal ao receptor que é importante. 

O segundo mecanismo para inserir marcadores de fim de registro em um byte é a operação push. 
Originalmente, esse mecanismo foi projetado para permitir que o processo emissor dissesse ao TCP que 
ele deveria enviar ao seu par quaisquer bytes que tivesse coletado (esvaziar o buffer). A operação push 
pode ser usada para implementar fronteiras de registro, pois a especificação diz que o TCP precisa enviar 
quaisquer dados mantidos no buffer de origem quando a aplicação disser “push” e, opcionalmente, o 
TCP no destino notifica à aplicação sempre que um segmento recebido possui o flag PUSH marcado. 
Se o lado receptor tiver suporte a essa opção (não é o caso da interface de sockets), então a operação 
push pode ser usada para dividir o fluxo TCP em registros. 

Naturalmente, o programa de aplicação sempre está livre para inserir fronteiras de registro sem qual- 
quer auxílio do TCP Por exemplo, ele pode enviar um campo que indica o tamanho de um registro que 
virá em seguida, ou pode inserir seus próprios marcadores de fronteira de registro ao fluxo de dados. 


5.2.8 Extensões do TCP 


Mencionamos em três pontos diferentes desta seção que, atualmente, existem extensões ao TCP que 
ajudam a aliviar algum problema que o TCP esteja enfrentando à medida que a rede básica se torna mais 
veloz. Essas extensões são projetadas para terem o menor impacto possível sobre o TCP Particularmente, 
elas são implementadas como opções que podem ser acrescentadas ao cabeçalho TCP (Passamos 
rapidamente por esse ponto, mas o motivo para que o cabeçalho TCP tenha um campo TamCab é que o 
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cabeçalho pode ter um tamanho variável; a parte variável do cabeçalho TCP contém as opções que foram 
acrescentadas.) O significado da inclusão dessas extensões como opções, ao invés de alterar o núcleo do 
cabeçalho TCP é que os hosts ainda podem se comunicar usando TCP mesmo que não implementem as 
opções. Porém, os hosts que implementam as extensões opcionais podem tirar proveito delas. Os dois 
lados concordam que usarão as opções durante a fase de estabelecimento de conexão do TCP 

A primeira extensão ajuda a melhorar o mecanismo de expiração de tempo limite do TCP Ao invés 
de medir o RTT usando um evento muito espaçado, o TCP pode ler o relógio real do sistema quando 
estiver para enviar um segmento, e colocar essa hora — pense nela como um carimbo de tempo de 32 
bits — no cabeçalho do segmento. O receptor, então, ecoa esse carimbo de tempo de volta ao emissor 
em sua confirmação, e o emissor subtrai esse carimbo de tempo da hora atual, a fim de medir o RTT. 
Essencialmente, a opção de carimbo de tempo de hora oferece um local conveniente para o TCP “arma- 
zenar” o registro de quando um segmento foi transmitido; ele armazena a hora no próprio segmento. 
Observe que as extremidades dessa conexão não precisam de relógios sincronizados, pois o carimbo 
de tempo é escrito e lido na mesma extremidade da conexão. 

A segunda extensão focaliza o problema do campo NúmeroSeg de 32 bits do TCP que reinicia 
muito rapidamente em uma rede de alta velocidade. Em vez de definir um novo campo de número de 
sequência de 64 bits, o TCP usa o carimbo de tempo de 32 bits, que acabamos de descrever, para efe- 
tivamente estender o espaço dos números de sequência. Em outras palavras, o TCP decide se aceitará 
ou rejeitará um segmento com base em um identificador de 64 bits que possui o campo NúmeroSeq nos 
32 bits menos significativos e o carimbo de tempo nos 32 bits mais significativos. Como o carimbo de 
tempo sempre está aumentando, ele serve para distinguir entre duas ocorrências diferentes do mesmo 
número de sequência. Observe que o carimbo de tempo está sendo usado nessa configuração apenas 
para proteger contra o reinício cíclio; ele não é tratado como parte do número de sequência para fins 
de ordenação ou confirmação de dados. 

Aterceira extensão permite que o TCP anuncie uma janela maior, permitindo, assim, que ele preen- 
cha “tubos” com valores maiores de atraso x largura de banda, que são possíveis devido a redes de alta 
velocidade. Essa extensão envolve uma opção que define um fator de escala à janela anunciada. Ou seja, 
ao invés de interpretar o número que aparece no campo JanelaAnunciada como indicando quantos 
bytes o emissor pode enviar sem confirmação, essa opção permite que os dois lados do TCP combinem 
que o campo JanelaAnunciada indica conjuntos de dados maiores (por exemplo, quantas unidades de 
16 bytes de dados o emissor pode ter sem confirmação). Em outras palavras, a opção de escala da janela 
especifica por quantos bits cada lado deverá deslocar à esquerda o campo JanelaAnunciada, antes de 
usar seu conteúdo para calcular uma janela efetiva. 

A quarta extensão permite que o TCP aumente seu conhecimento cumulativo com confirmações 
seletivas de quaisquer outros segmentos que tenham sido recebidos, mas que não sejam contíguos a 
todos os segmentos previamente recebidos. Essa é a opção de confirmação seletiva, ou SACK. Quando 
a opção SACK é usada, o receptor continua a confirmar os segmentos normalmente — o significado do 
campo Confirmação não muda —, mas ele também usa campos opcionais no cabeçalho para confirmar 
quaisquer blocos adicionais de dados recebidos. Isso permite que o emissor retransmita apenas os 
segmentos que estão faltando, de acordo com a confirmação seletiva. 

Sem o SACK, existem apenas duas estratégias razoáveis para o transmissor. A estratégia pessimista 
responde a uma expiração do tempo limite retransmitindo não apenas o segmento cujo tempo limite 
foi atingido, mas quaisquer segmentos transmitidos depois disso. Com efeito, a estratégia pessimista 
considera o pior caso: que todos esses segmentos foram perdidos. A desvantagem da estratégia pessi- 
mista é que ela pode retransmitir desnecessariamente segmentos que foram recebidos com sucesso 
na primeira vez. A outra estratégia é a estratégia otimista, que responde a uma expiração do tempo 
limite retransmitindo apenas o segmento cujo tempo limite foi atingido. Com efeito, a técnica otimista 
pressupõe o melhor cenário: que somente um segmento foi perdido. A desvantagem da estratégia 
otimista é que ela é muito lenta, desnecessariamente, quando uma série de segmentos consecutivos 
se perdeu, como poderia acontecer quando existe congestionamento. Ela é lenta porque a perda de 
cada segmento não é descoberta até que o emissor receba um ACK requisitando a retransmissão do 
segmento anterior. Assim, ela consome um RTT por segmento até que tenha retransmitido todos os 
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segmentos na sequência perdida. Com a opção de SACK, uma estratégia melhor está disponível para o 
emissor: retransmitir apenas os segmentos que preenchem as lacunas entre os segmentos que foram 
seletivamente confirmados. 

Essas extensões, a propósito, não são a história completa. Veremos mais algumas extensões no 
próximo capítulo, quando examinarmos como o TCP trata do congestionamento. A Internet Assigned 
Numbers Authority (IANA) mantém registro de todas as opções que são definidas para o TCP (e para 
muitos outros protocolos das Internet). Cerca de 30 opções do TCP foram definidas até o momento em 
que este livro foi escrito (porém, muitas são experimentais ou obsoletas). Veja, nas referências ao final 
deste capítulo, um link para o registro de números de protocolo da IANA. 


5.2.9 Desempenho 


Lembre-se que o Capítulo 1 introduziu as duas métricas quantitativas pelas quais o desempenho da 
rede é avaliado: latência e vazão. Como dissemos naquela ocasião, essas métricas são influenciadas não 
apenas pelo hardware subjacente (ou seja, atraso de propagação e largura de banda do enlace), mas 
também pela carga computacional (overhead) do software. Agora que temos à nossa disposição um 
grafo de protocolos completo baseado em software, que inclui protocolos de transporte alternativos, 
podemos discutir como medir seu desempenho de modo significativo. A importância de tais medições 
é que elas representam o desempenho visto pelos programas de aplicação. 

Começamos, como qualquer relatório de resultados experimentais deveria começar, descrevendo 
nosso método experimental. Isso inclui a aparelhagem usada nas experiências; cada estação de trabalho 
tem um par de processadores Xeon de 2,4 GHz dual executando Linux. Para permitir velocidades acima 
de 1 Gbps, um par de adaptadores Ethernet (denominados NIC, de Network Interface Card — placa de 
interface de rede) é usado em cada máquina. A Ethernet se estende por uma única sala, de modo que 
a propagação não é um problema, tornando essa uma medida de overhead de processador/software. 
Um programa de testes executado sobre a interface de sockets simplesmente tenta transferir dados o 
mais rápido possível de uma máquina para a outra. A Figura 5.11 ilustra essa configuração. 

Você pode ter notado que essa configuração experimental não é especialmente o que há de melhor 
em termos de hardware ou velocidade de enlace. O objetivo desta seção não é mostrar a velocidade com 
que determinado protocolo pode ser executado, mas ilustrar a metodologia geral para medir e relatar 
o desempenho do protocolo. 

O teste de vazão é realizado para diversos tamanhos de mensagem, usando uma ferramenta de 
medição de desempenho (benchmark) padrão, chamada TTCP Os resultados do teste de vazão são mos- 
trados na Figura 5.12. A principal coisa a observar nesse gráfico é que o vazão melhora à medida que as 
mensagens ficam maiores. Isso faz sentido — cada mensagem envolve certa quantidade de overhead, 
de modo que uma mensagem maior significa que esse overhead é amortizado por mais bytes. A curva 
da vazão se achata acima de 1 Kb, no ponto em que o overhead por mensagem se torna insignificante 
quando comparada com o grande número de bytes que a pilha de protocolos precisa processar. 


Processo do Processo do 
usuário usuário 
Kernel do Linux Kernel do Linux 

NIC NIC 
NIC NIC 


FIGURA 5.11 Sistema de medição: duas estações 
de trabalho executando Linux e um par de enlaces 
Gbps Ethernet. 
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1,8 FIGURA 5.12 Vazão medida usando TCP, para vários tamanhos 
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É interessante observar que a vazão máxima é menor do que 2 Gbps, a velocidade do enlace disponível 
dessa configuração. Seriam necessários outros teste e análise de resultados para descobrir onde está 
o gargalo (ou se existe mais de um). Por exemplo, a análise da carga da CPU poderia indicar se a CPU 
é o gargalo ou se o culpado é a largura de banda de memória, o desempenho do adaptador ou algum 
outro problema. 

Também notamos que a rede neste teste é basicamente “perfeita”. Ela quase não tem atraso ou perda, 
de modo que os únicos fatores que afetam o desempenho são a implementação do TCP e o hardware 
e software da estação de trabalho. Em comparação, na maior parte das vezes, lidamos com redes que 
estão longe de serem perfeitas, principalmente nossos enlaces de última milha, com largura de banda 
restrita, e enlaces sem fios passíveis de perdas. Antes de apreciarmos completamente como esses enlaces 
afetam o desempenho do TCP precisamos entender como o TOP lida com o congestionamento, que é 
o assunto da Seção 6.3. 

Em várias ocasiões na história das redes, a velocidade constantemente em crescimento dos enlaces 
de rede tem ameaçado seguir à frente do que poderia ser oferecido às aplicações. Por exemplo, um 
grande esforço de pesquisa foi iniciado nos Estados Unidos em 1989 para criar “redes gigabit”, em que 
o objetivo não era apenas criar enlaces e switches que pudessem operar a 1 Gbps ou mais, mas também 
oferecer essa vazão por todo o caminho até um único processo da aplicação. Existiram alguns problemas 
reais (por exemplo, adaptadores de rede, arquiteturas de estações de trabalho e sistemas operacionais 
tinham de ser projetados considerando a vazão da rede à aplicação) e também alguns problemas que 
se percebeu não serem tão sérios. No alto da lista desses problemas estava a preocupação de que os 
protocolos de transporte existentes, TCP em particular, não fossem capazes de enfrentar o desafio da 
operação em gigabit. 

Acontece que o TOP se saiu bem, acompanhando as demandas cada vez maiores das redes e apli- 
cações de alta velocidade. Um dos fatores mais importantes foi a introdução da escala de janela para 
lidar com maiores produtos atraso X largura de banda. Porém, geralmente existe uma grande diferença 
entre o desempenho teórico do TCP e o que é conseguido na prática. Problemas relativamente simples, 
como copiar os dados mais vezes do que o necessário enquanto eles passam de um adaptador de rede 
à aplicação, podem reduzir o desempenho, assim como uma memória de buffer insuficiente quando o 
produto atraso X largura de banda é grande. E a dinâmica do TCP é tão complexa (conforme ficará mais 
evidente no próximo capítulo) que interações sutis entre o comportamento da rede, o comportamento 
da aplicação e o próprio protocolo TCP podem alterar o desempenho drasticamente. 

Para os nossos propósitos, é interessante observar que o TCP continua a funcionar muito bem 
à medida que as velocidades da rede aumenta, e quando ele atinge algum limite (normalmente 
relacionado ao congestionamento, aumento de produtos atraso X largura de banda, ou ambos), os 
pesquisadores correm para encontrar soluções. Vimos algumas delas neste capítulo e veremos mais 
algumas no próximo. 
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5.2.10 Escolhas de projeto alternativas 


Embora o TCP tenha provado ser um protocolo robusto, que satisfaz às necessidades de uma grande 
variedade de aplicações, o espaço de projeto para os protocolos de transporte é muito grande. O TCB 
de forma alguma, é o único ponto válido nesse espaço de projeto. Concluímos nossa discussão do 
TCP considerando escolhas de projeto alternativas. Embora ofereçamos uma explicação de por que os 
projetistas do TCP fizeram suas escolhas, observamos que existem outros protocolos que fizeram outras 
escolhas, e mais protocolos poderão aparecer no futuro. 

Primeiro, sugerimos desde o primeiro capítulo deste livro que existem pelo menos duas classes 
interessantes de protocolos de transporte: protocolos orientados a fluxo, como TCP e protocolos de 
solicitação /resposta, como RPC. Em outras palavras, implicitamente dividimos o espaço de projeto ao 
meio e colocamos o TCP na metade do mundo orientada para fluxo. Poderíamos dividir ainda mais os 
protocolos orientados a fluxo em dois grupos - confiáveis e não confiáveis —, com o primeiro contendo 
o TCB e o segundo sendo mais adequado para aplicações de vídeo interativo, que prefeririam perder 
um quadro a incorrer no atraso associado a uma retransmissão. 

Este exercício de montagem da taxonomia de um protocolo de transporte é interessante e poderia 
continuar com cada vez mais detalhes, mas o mundo não é tão “preto no branco” como poderíamos 
desejar. Considere a adequação do TCP como protocolo de transporte para aplicações de solicitação/ 
resposta, por exemplo. O TCP é um protocolo full-duplex, de modo que seria fácil abrir uma conexão TCP 
entre o cliente e o servidor, enviar uma mensagem de solicitação em uma direção e enviar a mensagem 
de resposta na outra direção. Porém, existem duas complicações. A primeira é que o TCP é um protocolo 
orientado a bytes, e não um protocolo orientado a mensagens, e as aplicações de solicitação/resposta 
sempre lidam com mensagens. (Mais adiante, exploraremos essa questão de bytes versus mensagens 
com mais detalhes.) A segunda complicação é que, nas situações em que a mensagem de solicitação 
e a mensagem de resposta cabem em um único pacote da rede, um protocolo de solicitação/resposta 
bem projetado só precisa de dois pacotes para realizar a troca, enquanto o TCP precisaria de, pelo 
menos, nove: três para estabelecer a conexão, dois para a troca de mensagens e quatro para terminar 
a conexão. Naturalmente, se as mensagens de solicitação ou resposta forem grandes o bastante para 
exigirem múltiplos pacotes de rede (por exemplo, poderiam ser necessários 100 pacotes para enviar 
uma mensagem de resposta de 100.000 bytes), então o overhead da configuração e término da conexão 
seria insignificante. Em outras palavras, nem sempre um protocolo específico é incapaz de suportar 
certa funcionalidade; às vezes, acontece que um projeto é mais eficiente do que outro sob determinadas 
circunstâncias. 

Segundo, conforme sugerido, você poderia questionar por que o TCP escolheu oferecer um serviço 
de fluxo de bytes confiável em vez de um serviço de fluxo de mensagens confiável; as mensagens seriam 
a escolha natural para uma aplicação de banco de dados que quisesse trocar registros. Existem duas res- 
postas para essa pergunta. A primeira é que um protocolo orientado a mensagens, por definição, precisa 
estabelecer um limite máximo para os tamanhos de mensagem. Afinal, uma mensagem infinitamente 
longa é um fluxo de bytes. Para qualquer tamanho de mensagem que um protocolo selecione, haverá 
aplicações que desejam enviar mensagens maiores, tornando o protocolo de transporte inútil e forçando 
a aplicação a implementar seus próprios serviços do tipo transporte. A segunda razão é que, embora 
os protocolos orientados a mensagens sejam definitivamente mais apropriados para aplicações que 
queiram trocar registros, você pode facilmente inserir limites de registro em um fluxo de bytes para 
implementar essa funcionalidade, conforme descrevemos na Seção 5.2.7. 

Uma terceira decisão tomada no projeto do TCP é que ele entrega bytes ordenados para a aplicação. 
Isso significa que ele pode segurar os bytes que foram recebidos fora de ordem da rede, aguardando 
alguns bytes que faltam para preencher um espaço. Isso é tremendamente útil para muitas aplicações, 
mas é inútil se a aplicação for capaz de processar dados fora de ordem. Como um exemplo simples, 
uma página Web contendo várias imagens embutidas não precisa que todas as imagens sejam entregues 
na ordem antes de começar a exibir a página. De fato, existe uma classe de aplicações que preferiria 
tratar dos dados fora de ordem na camada da aplicação, em troca de receber dados mais cedo quando 
os pacotes são descartados ou desordenados dentro da rede. O desejo de dar suporte a essas aplicações 
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levou à criação de outro protocolo de transporte padrão do IETF conhecido como protocolo de controle 
de fluxo de transmissão (SCTP — Stream Control Transmission Protocol). O SCTP oferece um serviço de 
entrega parcialmente ordenado, em vez do serviço estritamente ordenado do TCP. (O SCTP também 
apresenta algumas outras escolhas de projeto que diferem do TCP incluindo orientação a mensagem e 
suporte a vários endereços IP para uma única sessão. Veja mais detalhes na Seção Leitura Adicional.) 

Em quarto lugar, o TCP escolheu implementar fases de configuração /encerramento explícitas, mas 
isso não é obrigatório. No caso da configuração da conexão, certamente seria possível enviar todos os 
parâmetros de conexão necessários junto com a primeira mensagem de dados. O TCP decidiu usar uma 
técnica mais conservadora, que dá ao receptor a oportunidade de rejeitar a conexão antes da chegada 
de qualquer dado. No caso do encerramento, poderíamos silenciosamente fechar uma conexão que es- 
teve inativa por um longo período de tempo, mas isso complicaria aplicações como Telnet, que desejam 
manter uma conexão ativa durante semanas; essas aplicações seriam forçadas a enviar mensagens de 
“keep alive” (manutenção da sessão) fora da banda, para evitar o desaparecimento do estado da conexão 
na outra ponta. 

Finalmente, o TCP é um protocolo baseado em janelas, mas essa não é a única possibilidade. A alter- 
nativa é um projeto baseado em taxa, em que o receptor diz ao emissor a taxa — expressa ou em bytes ou 
em pacotes por segundo — em que deseja aceitar os dados que chegam. Por exemplo, o receptor poderia 
informar ao emissor que pode acomodar 100 pacotes por segundo. Existe uma dualidade interessante 
entre janelas e taxa, pois o número de pacotes (bytes) na janela, dividido pelo RTT, é exatamente a 
taxa. Por exemplo, um tamanho de janela de 10 pacotes e um RTT de 100 ms implica que o emissor 
tem permissão para transmitir a uma taxa de 100 pacotes por segundo. É aumentando ou diminuindo 
o tamanho da janela anunciada que o receptor está efetivamente elevando ou reduzindo a taxa em que o 
emissor pode transmitir. No TCP essa informação é devolvida ao emissor no campo JanelaAnunciada 
da confirmação para cada segmento. Um dos principais problemas em um protocolo baseado em taxa é 
com que frequência a taxa desejada — que pode mudar com o tempo — é repassada de volta à origem: para 
cada pacote, uma vez por RTT ou apenas quando a taxa muda? Embora tenhamos agora considerado a 
questão de janela versus taxa no contexto do controle de fluxo, essa é uma questão ainda mais “quente” 
no contexto do controle de congestionamento, que discutiremos no Capítulo 6. 


5.3 Remote procedure call 


Conforme discutimos no Capítulo 1, um padrão de comunicação comum, usado pelos programas de 
aplicação, é o paradigma de solicitação/resposta, também chamado transação de mensagens: um cliente 
envia uma mensagem de solicitação a um servidor, o servidor responde com uma mensagem de res- 
posta, e o cliente bloqueia (suspende a execução) enquanto espera essa resposta. A Figura 5.13 ilustra 
a interação básica entre o cliente e o servidor em tal transação de mensagens. 

Um protocolo de transporte que suporta o paradigma de solicitação /resposta é muito mais do que 
uma mensagem UDP seguindo em uma direção, seguida por uma mensagem UDP seguindo na outra 
direção. Ele deve lidar com problemas como identificar corretamente processos em hosts remotos 
e correlacionar solicitações com respostas. Ele também pode ter que superar algumas ou todas as 
limitações da rede básica, brevemente discutidas na declaração do problema, no início deste capítulo. 


Cliente Servidor 
Solin: 
Olicitacãg Bloqueado 
Bloqueado | Computando 
Resposta 
Bloqueado 


FIGURA 5.13 Linha de tempo para a RPC. 
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Embora o TCP contorne essas limitações oferecendo um serviço de fluxo de bytes confiável, ele não 
combina muito bem com o paradigma de solicitação /resposta, pois ter o trabalho de estabelecer uma 
conexão TCP só para trocar um par de mensagens parece um exagero. Esta seção descreve uma terceira 
categoria de protocolo de transporte, a chamada de procedimento remoto (RCP — Remote Procedure Call), 
que combina melhor com as necessidades de uma aplicação envolvida em uma troca de mensagens 
de solicitação/resposta. 


5.3.1 Fundamentos de RPC 


A RPC é, na realidade, mais do que apenas um protocolo — é um mecanismo popular para estruturar sis- 
temas distribuídos. A RPC é popular porque é baseado na semântica de uma chamada de procedimento 
local - o programa de aplicação faz uma chamada a um procedimento sem considerar se ele é local 
ou remoto, e bloqueia até que a chamada retorne. Um desenvolvedor de aplicação pode não saber 
se o procedimento é local ou remoto, simplificando assim sua tarefa consideravelmente. Quando os 
procedimentos chamados são realmente métodos de objetos remotos em uma linguagem orientada a 
objetos, a RPC é conhecida como chamada de método remoto (RMI — Remote Method Invocation). Embora 
a RPC possa parecer simples, existem dois problemas principais que tornam a RPC mais complicado 
que as chamadas de procedimento local: 


e Arede entre o processo que chama e o processo chamado possui propriedades muito mais 
complexas do que a placa-mãe de um computador. Por exemplo, ela provavelmente limita os 
tamanhos de mensagem e tem uma tendência a perder e reordenar mensagens. 

e Os computadores em que são executados os processos chamador e chamado podem ter 
arquiteturas e formatos de representação de dados significativamente diferentes. 


Assim, um mecanismo de RCP completo na realidade envolve dois componentes principais: 


1. Um protocolo que gerencia as mensagens enviadas entre os processos cliente e servidor e que lida 
com as propriedades potencialmente indesejáveis da rede básica. 

2. Suporte da linguagem de programação e do compilador para empacotar os argumentos em uma 
mensagem de solicitação na máquina cliente e depois para traduzir essa mensagem de volta 
aos argumentos na máquina servidora, e fazer o mesmo com o valor de retorno (essa parte do 
mecanismo de RPC normalmente é chamada compilador stub). 


A Figura 5.14 representa esquematicamente o que acontece quando um cliente chama um pro- 
cedimento remoto. Primeiro, o cliente chama um stub local para o procedimento, passando-lhe os 
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FIGURA 5.14 Mecanismo de RPC completo. 
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argumentos exigidos pelo procedimento. Esse stub esconde o fato de que o procedimento é remoto, 
traduzindo os argumentos para uma mensagem de solicitação e depois chamando um protocolo RPC 
para enviar a mensagem de solicitação à máquina servidora. No servidor, o protocolo RPC entrega a 
mensagem de solicitação ao stub do servidor (também chamado de esqueleto), que a traduz para os 
argumentos do procedimento e depois chama o procedimento local. Depois que o procedimento do 
servidor termina, ele retorna a resposta ao stub do servidor, que empacota esse valor de retorno em 
uma mensagem de resposta que ele entrega ao protocolo RPC para transmissão de volta ao cliente. O 
protocolo RPC no cliente passa essa mensagem para o stub do cliente, que a traduz para um valor de 
retorno que ele retorna ao programa cliente. 

Esta seção considera apenas os aspectos de protocolo de um mecanismo de RPC. Ou seja, ele ignora 
os stubs e, em vez disso, se concentra no protocolo RPC, também chamado protocolo de solicitação/res- 
posta, que transmite mensagens entre cliente e servidor. A transformação de argumentos em mensagens 
e vice-versa é explicada no Capítulo 7. 

O termo RPC refere-se a um tipo de protocolo, em vez de um padrão específico como TCP de modo 
que protocolos RPC específicos variam nas funções que eles realizam. E, diferente do TCP que é o 
protocolo de fluxo de bytes confiável dominante, não existe um protocolo RPC dominante. Assim, nesta 
seção, falaremos mais sobre escolhas de projeto alternativas do que anteriormente. 


QUAL É A CAMADA RPC? 


Mais uma vez, a pergunta “em que camada isso se encontra?” mostra sua “cara feia”. Para muitas pessoas, 
especialmente aquelas que aderem a uma visão estritamente em camadas da arquitetura de protocolos, a 
RPC é implementada em cima de um protocolo de transporte (normalmente, UDP) e por isso não pode, por 
si só (por definição), ser um protocolo de transporte. Porém, é igualmente válido argumentar que a Internet 
deveria ter um protocolo RPC, pois ele oferece um serviço processo a processo fundamentalmente diferente 
daquele oferecido pelo TCP e pelo UDP Entretanto, a resposta normal para tal sugestão é que a arquitetura 
da Internet não proíbe os projetistas de rede de implementarem seu próprio protocolo RPC em cima do UDP. 
Qualquer que seja o lado em que você se encontra na questão de se a Internet deve ter um protocolo RPC 
oficial, o importante é que o modo como você implementa a RPC na arquitetura da Internet não diz nada a 
respeito sobre se a RPC deve ser considerada um protocolo de transporte ou não. 

É interessante que existem outras pessoas que acreditam que RPC é o protocolo mais interessante 
do mundo, e que TCP/IP é apenas o que você faz quando quer “uma válvula de escape”. Essa é a visão 
predominante na comunidade de sistemas operacionais, que criou inúmeros kernels de SO para sistemas 
distribuídos que contêm exatamente um protocolo — isso mesmo, RPC — executando em cima de um driver 
de dispositivo de rede. 

Nossa posição é que qualquer protocolo que ofereça serviço processo a processo, ao contrário 
de um serviço nó a nó ou host a host, qualifica-se como um protocolo de transporte. Assim, RPC é um 
protocolo de transporte e, de fato, pode ser implementado a partir de uma combinação de microprotocolos 
que, por si próprios, são protocolos de transporte válidos. 





Identificadores no RPC 
Duas funções que precisam ser realizadas por um protocolo RPC são: 


e Oferecer um espaço de nomes para identificar univocamente o procedimento a ser chamado. 
e Fazer a correspondência entre cada mensagem de resposta e a mensagem de solicitação 
correspondente. 


O primeiro problema tem algumas semelhanças com o problema de identificar os nós em uma rede, 
algo que vimos nos capítulos anteriores (endereços IP por exemplo, no Capítulo 4). Uma das opções 
de projeto, quando se identifica as coisas, é se esse nome será simples ou hierárquico. Um espaço de 
nomes simples meramente atribuiria um identificador exclusivo, não estruturado (por exemplo, um 
número inteiro) a cada procedimento, e esse número seria transportado em um único campo em uma 
mensagem de solicitação RPC. Isso exigiria algum tipo de coordenação central para evitar atribuição 
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do mesmo número de procedimento a dois procedimentos diferentes. Como alternativa, o protocolo 
poderia implementar um espaço de nomes hierárquico, semelhante ao que é usado para nomes de 
caminho de arquivo, o que exige apenas que o “nome de base” de um arquivo seja exclusivo dentro do 
seu diretório. Essa técnica simplifica potencialmente a tarefa de garantir a exclusividade dos nomes 
de procedimento. Um espaço de nomes hierárquico para o RPC poderia ser implementado definindo 
um conjunto de campos no formato das mensagens de solicitação, um para cada nível de nomeação, 
digamos, em um espaço de nomes hierárquico de dois ou três níveis. 

A chave para combinar uma mensagem de resposta à solicitação correspondente é identificar uni- 
vocamente os pares de solicitação-resposta usando um campo de ID da mensagem. Uma mensagem 
de resposta teria seu campo de ID de mensagem definido com o mesmo valor da mensagem de solici- 
tação. Quando o módulo RPC do cliente recebe a resposta, ele usa a ID da mensagem para procurar a 
solicitação pendente correspondente. Para fazer com que a transação RPC se pareça com uma chamada 
de procedimento local para o processo que fez a chamada, este processo é bloqueado (por exemplo, 
usando um semáforo) até que a mensagem de resposta seja recebida. Quando a resposta é recebida, 
o processo chamador é identificado com base no número de solicitação presente na resposta, o valor 
de retorno do procedimento remoto é obtido da resposta e o processo chamador é desbloqueado para 
que possa continuar sua operação usando esse valor de retorno. 

Um dos desafios recorrentes no RPC é lidar com respostas inesperadas, e vemos isso com IDs de 
mensagem. Por exemplo, considere a seguinte situação patológica (porém realista). Uma máquina cliente 
envia uma mensagem de solicitação com um ID de mensagem igual a 0, depois falha e é reiniciada, e 
então envia uma mensagem de solicitação não relacionada, também com o ID de mensagem igual a 0. 
O servidor pode não saber que o cliente falhou e reinicializou e, ao ver uma mensagem de solicitação 
com um ID de mensagem 0, a confirma sua recepção e a descarta como uma duplicata. O cliente nunca 
recebe uma resposta para a solicitação. 

Uma maneira de eliminar esse problema é usar um ID de inicialização. O ID de inicialização de uma 
máquina é um número que é incrementado toda vez que a máquina é reiniciada; esse número é lido de 
um dispositivo de armazenamento não volátil (por exemplo, um disco ou flash drive), incrementado e 
escrito de volta no dispositivo de armazenamento durante o procedimento de inicialização da máquina. 
Esse número é então colocado em cada mensagem enviada por esse host. Se uma mensagem é recebida 
com um ID de mensagem antigo, mas com um ID de inicialização novo, ela é reconhecida como uma 
mensagem nova. Com efeito, o ID de mensagem e o ID de inicialização se combinam para formar um 
ID exclusivo para cada transação. 


Superando limitações na rede 
Protocolos RPC normalmente realizam funções adicionais para lidar com o fato de que as redes não 
são canais perfeitos. Duas dessas funções são: 


e Oferecer entrega de mensagens confiável. 
e Admitir tamanhos de mensagem grandes por meio da fragmentação e remontagem. 


Um protocolo RPC poderia implementar a confiabilidade porque os protocolos básicos (por exem- 
plo, UDP/IP) não a oferecem, ou talvez para recuperar-se mais rápida ou eficientemente de falhas que, 
de outra forma, seriam em algum momento reparadas pelos protocolos básicos. Um protocolo RCP pode 
implementar a confiabilidade usando confirmações e temporizadores de expiração, de modo semelhante ao 
TCP O algoritmo básico é simples, conforme ilustra a linha de tempo dada na Figura 5.15. O cliente 
envia uma mensagem de solicitação e o servidor a confirma. Depois, após executar o procedimento, o 
servidor envia uma mensagem de resposta e o cliente confirma a resposta. 

Uma mensagem transportando dados (uma mensagem de solicitação ou de resposta) ou o ACK 
enviado para confirmar essa mensagem podem se perder na rede. Para levar em conta essa possibilidade, 
tanto o cliente como o servidor salvam uma cópia de cada mensagem enviada até que chegue um ACK 
para ela. Cada lado também define um temporizador de retransmissão e reenvia a mensagem caso esse 
temporizador expire. Os dois lados reiniciam esse temporizador e tentam novamente por algum número 
de vezes previamente acordado antes de desistir e remover a cópia da mensagem. 


268 REDES DE COMPUTADORES ELSEVIER 


Cliente Servidor Cliente Servidor 


Solicita ção 






repostê 
ACk 
FIGURA 5.15 Linha de tempo simples FIGURA 5.16 Linha de tempo para um protocolo 
para um protocolo RPC confiável. RPC confiável usando confirmação implícita. 


Se um cliente RPC recebe uma mensagem de resposta, claramente a mensagem de solicitação corres- 
pondente deve ter sido recebida pelo servidor. Logo, a própria mensagem é uma confirmação implícita, 
e qualquer confirmação adicional do servidor não é logicamente necessária. De modo semelhante, uma 
mensagem de solicitação poderia implicitamente confirmar a mensagem de resposta anterior - supondo 
que o protocolo realize transações de solicitação /resposta sequenciais, de modo que uma transação 
precisa ser concluída antes que a próxima comece. Infelizmente, essa sequenciação limitaria bastante 
o desempenho do RPC. 

Um modo de superar essa situação desagradável é fazer com que o protocolo RPC implemente 
uma abstração de canal. Dentro de determinado canal, as transações de solicitação /resposta são 
sequenciais — só pode haver uma transação ativa em determinado canal em determinado instante -, 
mas podem existir vários canais. Cada mensagem inclui um campo de ID de canal para indicar a qual 
canal a mensagem pertence. Uma mensagem de solicitação em determinado canal confirmaria im- 
plicitamente a resposta anterior nesse canal, se ela ainda não estivesse confirmada. Um programa de 
aplicação pode abrir vários canais com um servidor, se quiser ter mais de uma transação de solicitação / 
resposta entre eles ao mesmo tempo (a aplicação precisaria ter múltiplas linhas de execução, também 
conhecidas como threads). Conforme ilustramos na Figura 5.16, a mensagem de resposta serve para 
confirmar a mensagem de solicitação, e uma solicitação subsequente confirma a resposta anterior. 
Observe que vimos uma técnica muito semelhante — chamada canais lógicos concorrentes — na Seção 
2.5.3, como um modo de melhorar o desempenho de um mecanismo de confiabilidade do tipo parar 
e esperar. 

Outra complicação que o RPC precisa enfrentar é que o servidor pode precisar de muito tempo para 
produzir o resultado e, pior ainda, pode falhar antes de gerar a resposta. Lembre-se que estamos falando 
sobre o período de tempo após o servidor ter confirmado a solicitação, mas antes que envie a resposta. 
Para ajudar o cliente a distinguir entre um servidor lento e um servidor inativo, o lado do cliente do 
RPC pode enviar periodicamente uma mensagem “você está vivo?” ao servidor, e o lado do servidor 
responder com um ACK. Como alternativa, o servidor poderia enviar mensagens “ainda estou vivo” ao 
cliente, sem que o cliente as tenha solicitado primeiro. A técnica iniciada pelo cliente é mais escalável, 
pois coloca uma parcela maior do peso por cliente (controlando o a expiração do temporizador) sobre 
os clientes. 

A confiabilidade do RPC pode incluir a propriedade conhecida como semântica “no máximo uma 
vez”. Isso significa que, para cada mensagem de solicitação que o cliente envia, no máximo uma cópia 
dessa mensagem é entregue ao servidor. Toda vez que o cliente chama um procedimento remoto, esse 
procedimento é chamado, no máximo, uma vez na máquina do servidor. Dizemos “no máximo uma 
vez” em vez de “exatamente uma vez” porque sempre é possível que a rede ou a máquina do servidor 
tenha falhado, tornando impossível entregar até mesmo uma cópia da mensagem de solicitação. 

Para implementar a semântica “no máximo uma vez”, o RPC no lado do servidor precisa reconhecer 
solicitações duplicadas (e ignorá-las), mesmo que já tenha respondido com sucesso à solicitação original. 
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Logo, ele mantém alguma informação de estado que identifica as solicitações passadas. Uma técnica 
é identificar as solicitações usando números de sequência, de modo que um servidor só precisa se 
lembrar do número de sequência mais recente. Infelizmente, isso limitaria um RPC a uma solicitação 
pendente (com determinado servidor) de cada vez, pois uma solicitação precisa ser completada antes 
que a solicitação com o próximo número de sequência possa ser transmitida. Mais uma vez, os canais 
oferecem uma solução. O servidor poderia reconhecer solicitações duplicadas lembrando-se do número 
de sequência atual para cada canal, sem limitar o cliente a uma solicitação por vez. 

Por mais óbvia que a técnica “no máximo uma vez” possa parecer, nem todos os protocolos RPC 
têm suporte a esse comportamento. Alguns aceitam uma semântica que é estranhamente chamada 
semântica “zero ou mais”; ou seja, cada chamada em um cliente resulta no procedimento remoto 
sendo chamado “zero ou mais vezes”. Não é difícil entender como isso causaria problemas para um 
procedimento remoto que mudasse alguma variável de estado local (por exemplo, incrementasse 
um contador) ou que tivesse algum efeito colateral visível externamente (por exemplo, disparasse um 
míssil) toda vez que fosse chamado. Por outro lado, se o procedimento remoto sendo chamado for 
coerente — várias chamadas tiverem o mesmo efeito que uma -, então o mecanismo de RPC não precisa 
dar suporte à semântica “no máximo uma vez”; uma implementação mais simples (possivelmente mais 
rápida) será suficiente. 

Assim como foi no caso da confiabilidade, os dois motivos pelos quais o protocolo RPC poderia 
implementar a fragmentação e remontagem de mensagem são que isso não é fornecido pela pilha de 
protocolos básica ou que pode ser implementado de forma mais eficiente pelo protocolo RPC. Considere 
o caso em que o RPC é implementado em cima do UDP/IP e depende do IP para a fragmentação e 
remontagem. Mesmo que um fragmento de uma mensagem deixe de chegar dentro de certo período 
de tempo, o IP descarta os fragmentos que chegaram e a mensagem é efetivamente perdida. Por fim, o 
protocolo RPC (supondo que ele implementa a confiabilidade) atingiria o tempo limite e retransmitiria 
a mensagem. Em comparação, considere um protocolo RPC que implementa sua própria fragmentação 
e remontagem e agressivamente confirma (com ACKs) ou nega (com NACKs) a recepção dos fragmentos 
individuais. Os fragmentos perdidos seriam detectados e retransmitidos mais rapidamente, e somente 
os fragmentos perdidos seriam retransmitidos, e não a mensagem inteira. 


Protocolos síncronos e assíncronos 

Um modo de caracterizar um protocolo é definindo se ele é síncrono ou assíncrono. O significado exato 
desses termos depende de onde, na hierarquia de protocolos, você os utiliza. Na camada de transporte, 
é mais preciso pensar neles como definindo os extremos de uma faixa de possibilidades em vez de 
duas alternativas mutuamente exclusivas. O atributo chave de qualquer ponto ao longo desta faixa é o 
quanto o processo transmissor sabe após o retorno da operação de enviar uma mensagem. Em outras 
palavras, se considerarmos que um programa de aplicação chama uma operação send provida por um 
protocolo de transporte, então exatamente o que a aplicação sabe sobre o sucesso da operação quando 
a operação send retorna? 

No extremo assíncrono do espectro, a aplicação não sabe absolutamente nada quando send retorna. 
Ele não apenas não sabe se a mensagem foi recebida por seu par, mas nem sequer sabe ao certo se 
a mensagem saiu com sucesso da máquina local. No extremo síncrono do espectro, a operação send 
normalmente retorna uma mensagem de resposta. Ou seja, a aplicação não apenas sabe que a men- 
sagem enviada foi recebida por seu par, mas também sabe que o par retornou uma resposta. Assim, 
os protocolos síncronos implementam a abstração de solicitação/resposta, enquanto os protocolos 
assíncronos são usados se o transmissor quiser ser capaz de transmitir muitas mensagens sem ter 
que esperar por uma resposta. Usando essa definição, os protocolos RPC são obviamente protocolos 
síncronos. 

Embora não tenhamos discutido neste capítulo, existem pontos interessantes entre esses dois ex- 
tremos. Por exemplo, o protocolo de transporte poderia implementar a operação send de modo que 
ela bloqueie (não retorne) até que a mensagem tenha sido recebida com sucesso na máquina remota, 
mas retorne antes que o par do emissor naquela máquina a tenha realmente processado e respondido 
a ela. Isso também é chamado de protocolo de datagramas confiável. 
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5.3.2 Implementações do RPC (SunRPC, DCE) 


Agora vamos voltar nossa atenção para alguns exemplos de implementação dos protocolos RPC. Estes 
servirão para destacar algumas das diferentes decisões de projeto que os projetistas de protocolo 
tiveram que tomar. Nosso primeiro exemplo é o SunRPC, um protocolo RPC bastante utilizado, 
também conhecido como Open Network Computing RPC (ONC RPC). Nosso segundo exemplo, 
que vamos chamar de DCE-RPC, faz parte do Distributed Computing Environment (DCE). DCE é 
um conjunto de padrões e software para a elaboração de sistemas distribuídos, definido pela Open 
Software Foundation (OSF), um consórcio de empresas de computação que incluía originalmente 
IBM, Digital Equipment Corporation e Hewlett-Packard; hoje, a OSF recebe o nome de The Open 
Group. Esses dois exemplos representam escolhas alternativas de projeto interessantes no espaço 
de soluções do RPC. 


SunRPC 

O SunRPC tornou-se um padrão de fato graças à sua ampla distribuição com as estações de trabalho 
Sun e o papel central que ele desempenha no popular Network File System (NFS) da Sun. A IETF mais 
tarde o adotou como um protocolo padrão da Internet, sob o nome ONC RPC. 

O SunRPC pode ser implementado sobre vários protocolos de transporte diferentes. A Figura 5.17 
ilustra o grafo de protocolos quando o SunRPC é implementado sobre UDP Conforme observamos 
anteriormente nesta seção, um adepto à utilização estrita de camadas poderia questionar a ideia de 
executar um protocolo de transporte sobre um protocolo de transporte, ou argumentar que o RPC precisa 
ser algo diferente de um protocolo de transporte, pois ele aparece “acima” da camada de transporte. 
Pragmaticamente, a opção de projeto de executar o RPC sobre uma camada de transporte existente faz 
muito sentido, conforme ficará claro na discussão a seguir. 

O SunRPC utiliza endereços de dois níveis para identificar procedimentos remotos: um número de 
programa de 32 bits e um número de procedimento de 32 bits. (Há também um número de versão 
de 32 bits, mas vamos ignorar isso na discussão a seguir.) Por exemplo, o servidor NFS recebeu o 
número de programa x00100008 e, dentro desse programa, getattr é o procedimento 1, setattr é 
o procedimento 2, read é o procedimento 6, write é o procedimento 8, e assim por diante. O número do 
programa e o número do procedimento são transmitidos no cabeçalho da mensagem de solicitação do 
SunRPC, cujos campos aparecem na Figura 5.18. O servidor - que pode dar suporte a vários números 
de programa - é responsável por chamar o procedimento especificado do programa especificado. Uma 
solicitação SunRPC na realidade representa uma solicitação para chamar o programa e o procedimento 
especificados na máquina em particular à qual a solicitação foi enviada, embora o mesmo número de 
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programa possa ser implementado em outras máquinas na mesma rede. Assim, o endereço da máquina 
do servidor (por exemplo, um endereço IP) é uma terceira camada implícita do endereço RPC. 

Diferentes números de programa podem pertencer a diferentes servidores na mesma máquina. Esses 
diferentes servidores têm diferentes chaves demux da camada de transporte (por exemplo, portas UDP), 
a maioria delas não sendo números bem conhecidos, mas sim atribuídas dinamicamente. Essas chaves 
demux são chamadas seletores de transporte. Como um cliente SunRPC que deseja falar com um programa 
em particular determina qual seletor de transporte usar para alcançar o servidor correspondente? A solução 
é atribuir um endereço bem conhecido a apenas um programa na máquina remota e permitir que esse pro- 
grama trate da tarefa de dizer aos clientes qual seletor de transporte usar para alcançar qualquer outro pro- 
grama na máquina. A versão original desse programa SunRPC é chamada Mapeador de Portas (Port Mapper), 
e ele admite apenas UDP e TCP como protocolos subjacentes. Seu número de programa é x00100000, e sua 
porta bem conhecida é 111. O RPCBIND, que evoluiu do Port Mapper, aceita quaisquer protocolos de trans- 
porte subjacentes. À medida que cada servidor SunRPC é iniciado, ele chama um procedimento de registro 
RPCBIND, na própria máquina local do servidor, para registrar seu seletor de transporte e os números de 
programa que ele admite. Um cliente remoto pode, então, chamar um procedimento de busca do RPCBIND 
para procurar o seletor de transporte para um número de programa em particular. 

Para tornar isso mais concreto, considere um exemplo usando o Port Mapper com UDP Para enviar 
uma mensagem de solicitação ao procedimento read do NFS, um cliente primeiro envia uma mensagem 
de solicitação ao Port Mapper na porta UDP bem conhecida 111, pedindo que o procedimento 3 seja 
chamado para mapear o número de programa x00100003 à porta UDP onde o programa NFS atualmente 
reside. O cliente, então, envia uma mensagem de solicitação do SunRPC com o número de procedimento 
6 para essa porta UDP e o módulo do SunRPC escutando nessa porta chama o procedimento read do 
NFS. O cliente também coloca o mapeamento entre programa e porta em seu cache, para que não 
precise retornar ao Port Mapper toda vez que quiser falar com o programa NFS. 

Para fazer a correspondência entre uma mensagem de resposta e a solicitação correspondente, 
de modo que o resultado do RPC possa ser retornado a quem chamou, os cabeçalhos das mensagens de 
solicitação e de resposta incluem ambos um campo XID (ID de transação), como na Figura 5.18. Um 
XID é um ID de transação exclusivo, usado somente por uma solicitação e pela resposta correspondente. 
Depois que o servidor tiver respondido com sucesso a determinada solicitação, ele não se lembra do 
XID. Por causa disso, o SunRPC não pode garantir a semântica “no máximo uma vez”. 

Os detalhes da semântica do SunRPC dependem do protocolo de transporte básico. Ele não im- 
plementa sua própria confiabilidade, de modo que ele só é confiável se o transporte subjacente for 
confiável. (Naturalmente, qualquer aplicação que seja executada sobre o SunRPC também pode decidir 
implementar seus próprios mecanismos de confiabilidade acima do nível do SunRPC.) A capacidade de 
enviar mensagens de solicitação e resposta maiores que a MTU da rede também depende do transporte 
subjacente. Em outras palavras, o SunRPC não tenta de forma alguma melhorar o transporte subjacente 
quando se trata de confiabilidade e tamanho da mensagem. Como o SunRPC pode ser executado sobre 
muitos protocolos de transporte diferentes, isso lhe dá uma flexibilidade considerável sem complicar 
o projeto do próprio protocolo RPC. 

Retornando ao formato de cabeçalho do SunRPC da Figura 5.18, a mensagem de solicitação contém 
campos Credenciais e Verificador de tamanho variável, ambos usados pelo cliente para autenticar-se 
junto ao servidor, ou seja, para dar evidência de que o cliente tem o direito de chamar o servidor. Como 
um cliente se autentica para um servidor é uma questão geral que precisa ser resolvida por qualquer 
protocolo que queira oferecer um nível de segurança razoável. Esse assunto será discutido com mais 
detalhes no próximo capítulo. 


DCE-RPC 
O DCE-RPC é o protocolo RPC que faz parte do núcleo do sistema DCE e foi a base do mecanismo de 
RPC por trás do DCOM e do ActiveX da Microsoft. Ele pode ser usado com o compilador stub Network 


Na prática, o NFS é um programa tão importante que recebe sua própria porta bem conhecida, mas, para fins 
de ilustração, estamos considerando que isso não acontece. 
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Data Representation (NDR), descrito no Capítulo 7, mas também serve como o protocolo RPC subjacente 
para a Common Object Request Broker Architecture (CORBA), que é um padrão da indústria para a cons- 
trução de sistemas distribuídos orientados a objeto. 

O DCE-RPC, assim como o SunRPC, pode ser implementado em cima de vários protocolos de 
transporte, incluindo UDP e TCP Ele também é semelhante ao SunRPC porque define um esquema 
de endereçamento em dois níveis: o protocolo de transporte demultiplexa para o servidor correto, o DCE-RPC 
despacha para determinado procedimento exportado por esse servidor, e os clientes consultam um 
“servidor de mapeamento de sistema final” (semelhante ao Port Mapper do SunRPC) para descobrir 
como alcançar determinado servidor. Porém, ao contrário do SunRPC, o DCE-RPC implementa a 
semântica de chamada “no máximo uma vez”. (Na verdade, o DCE-RPC admite várias semânticas de 
chamada, incluindo uma semântica coerente, semelhante à do SunRPC, mas “no máximo uma vez” é 
o comportamento padrão.) Existem outras diferenças entre os dois métodos, que destacaremos nos 
próximos parágrafos. 

A Figura 5.19 mostra uma linha de tempo para uma troca típica de mensagens, onde cada mensagem 
é rotulada por seu tipo DCE-RPC. O cliente envia uma mensagem Request, o servidor por fim responde 
com uma mensagem Response, e o cliente confirma (envia um Ack) a resposta. Porém, em vez de o 
servidor confirmar as mensagens de solicitação, o cliente periodicamente envia uma mensagem Ping 
ao servidor, que responde com uma mensagem Working, para indicar que o procedimento remoto 
ainda está em andamento. Se a resposta do servidor for recebida em um tempo razoavelmente rápido, 
nenhum Ping é enviado. Embora não sejam mostrados na figura, outros tipos de mensagens também 
são aceitos. Por exemplo, o cliente pode enviar uma mensagem Quit ao servidor, pedindo que aborte 
uma chamada anterior que ainda esteja em andamento; o servidor responde com um Quack (QUit 
ACKnowledgment — confirmação do comando de abortar). Além disso, o servidor pode responder a uma 
mensagem Request com uma mensagem Reject (indicando que uma chamada foi rejeitada), e pode 
responder a uma mensagem Ping com uma mensagem Nocall (indicando que o servidor não conhece 
quem está chamando). 

Cada transação de solicitação/resposta no CDE-RPC ocorre no contexto de uma atividade. Uma 
atividade é um canal lógico de solicitação /resposta entre um par de participantes. Em determinado 
momento, só pode haver uma transação de mensagem ativa em determinado canal. Assim como o 
método de canal lógico concorrente descrito acima e na Seção 2.5.3, os programas de aplicação precisam 
abrir vários canais se quiserem ter mais de uma transação de solicitação /resposta entre eles ao mesmo 
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FIGURA 5.19 Troca de mensagem DCE-RPC típica. 
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tempo. A atividade à qual uma mensagem pertence é identificada pelo campo IdAtividade da mensagem. 
Um campo NúmeroSeg, então, distingue entre as chamadas feitas como parte da mesma atividade; ele 
tem a mesma finalidade dos campos XID (transaction id) do SunRPC. Ao contrário do SunRPC, o DCE 
-RPC registra o último número de sequência usado como parte de uma atividade específica, a fim de 
garantir a semântica “no máximo uma vez”. Para distinguir entre as respostas enviadas antes e depois 
que uma máquina servidora é reiniciada, o DCE-RPC usa um campo ServerBoot para armazenar o ID 
de inicialização da máquina. 

Outra escolha de projeto feita no DCE-RPC, que difere do SunRPC, é o suporte a fragmentação e 
remontagem no protocolo RPC. Como vimos, mesmo que um protocolo básico como o IP ofereça 
fragmentação /remontagem, um algoritmo mais sofisticado, implementado como parte do RPC, pode 
resultar em recuperação mais rápida e menor consumo de largura de banda quando os fragmentos 
se perdem. O campo NúmeroFrag identifica univocamente cada fragmento que compõe determinada 
mensagem de solicitação ou resposta. Cada fragmento DCE-RPC recebe um número de fragmento 
exclusivo (por exemplo, 0, 1, 2, 3 e assim por diante). Tanto o cliente como o servidor implementam 
um mecanismo de confirmação seletiva, que funciona conforme explicamos a seguir. (Descrevemos o 
mecanismo em termos de um cliente enviando uma mensagem de solicitação fragmentada ao servidor; 
o mesmo mecanismo se aplica quando um servidor envia uma resposta fragmentada ao cliente.) 

Primeiro, cada fragmento que compõe a mensagem de solicitação contém um NúmeroFrag exclusivo 
e um marcador indicando se esse pacote é um fragmento de uma chamada (frag) ou o último fragmento 
de uma chamada (last frag); as mensagens de solicitação que cabem em um único pacote transportam 
um marcador no frag. O servidor sabe que recebeu a mensagem de solicitação completa quando possui 
o pacote last frag e não existem lacunas nos números de fragmento. Segundo, em resposta a cada 
fragmento que chega, o servidor envia uma mensagem Fack (confirmação de fragmento) ao cliente. 
Essa confirmação identifica o número do fragmento mais alto que o servidor recebeu com sucesso. Em 
outras palavras, a confirmação é cumulativa, assim como no TCP Porém, além disso, o servidor confirma 
seletivamente quaisquer números de fragmento maiores que ele tenha recebido fora de ordem. Ele faz 
isso com um vetor de bits que identifica esses fragmentos fora de ordem em relação ao fragmento mais 
alto que ele recebeu. Finalmente, o cliente responde retransmitindo os fragmentos que faltaram. 

A Figura 5.20 ilustra como tudo isso funciona. Suponha que o servidor tenha recebido com sucesso 
os fragmentos até o número 20, mais os fragmentos 23, 25 e 26. O servidor responde com um Fack que 
identifica o fragmento 20 como o fragmento mais alto recebido em ordem, e mais um vetor de bits 
(ConfSel) com o terceiro (23=20+3), quinto (25=20+5) e sexto (26=20+6) bits marcados. Assim, para 
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dar suporte a um vetor de bits (quase) arbitrariamente longo, o tamanho do vetor (medido em palavras 
de 32 bits) é especificado no campo TamConfSel. 

Dado o suporte do DCE-RPC para mensagens muito grandes — o campo NúmeroFrag possui 16 
bits de extensão, o que significa que ele é capaz de suportar 64 K fragmentos -, não é apropriado que 
o protocolo envie todos os fragmentos que compõem uma mensagem o mais rápido que puder, pois 
isso poderia ultrapassar a capacidade do receptor. Em vez disso, o DCE-RPC implementa um algoritmo 
de controle de fluxo, que é muito semelhante ao do TCP Especificamente, cada mensagem Fack não 
apenas confirma os fragmentos recebidos, mas também informa ao emissor quantos fragmentos ele 
pode enviar agora. Essa é a finalidade do campo TamJanela da Figura 5.20, que tem exatamente a mesma 
finalidade do campo JanelaAnunciada do TCP exceto que ele conta fragmentos, ao invés de bytes. O 
DCE-RPC também implementa um mecanismo de controle de congestionamento que é semelhante ao 
do TCP que veremos no Capítulo 6. Dada a complexidade do controle de congestionamento, talvez não 
seja surpresa que alguns protocolos RPC o evitem, o que é feito evitando a fragmentação. 

Resumindo, os projetistas possuem muitas opções em aberto ao projetar um protocolo RPC. O 
SunRPC usa o método mais minimalista e agrega relativamente pouco ao transporte básico, além do 
essencial de localizar o procedimento correto e identificar mensagens. O DCE-RPC acrescenta mais 
funcionalidade, com a possibilidade de um desempenho melhorado em alguns ambientes, ao custo 
de maior complexidade. 


5.4 Real-time transport protocol (RTP) 


Nos primórdios da comutação de pacotes, a maioria das aplicações se preocupava com a movimentação 
de dados: acessar recursos de computação remotos, transferir arquivos, enviar e-mail etc. Porém, pelo 
menos por volta de 1981, havia experimentos para transportar tráfego em tempo real, como amostras 
de voz digitalizada, por redes de pacotes. Chamamos uma aplicação de “tempo real” quando ela tem 
fortes requisitos de que a informação seja entregue em tempo. A telefonia por Internet, ou Voz sobre 
IP (Voice over IP -- VoIP), é um exemplo clássico de uma aplicação de tempo real, pois você não pode 
ter uma conversa facilmente com alguém se levar mais do que uma fração de segundo para receber 
uma resposta. Conforme veremos em breve, as aplicações em tempo real colocam algumas demandas 
específicas sobre o protocolo de transporte, que não são bem atendidas pelos protocolos discutidos 
até aqui neste capítulo. 

As aplicações de multimídia — aquelas que envolvem vídeo, áudio e dados -, às vezes são divididas 
em duas classes: aplicações interativas e aplicações de streaming. Um exemplo popular da primeira 
classe é o vat, uma ferramenta de audioconferência com suporte a múltiplas partes que normalmente 
é utilizada em cima de redes que admitem multicast IP O painel de controle para uma conferência vat 
típica é mostrado na Figura 5.21. A telefonia por Internet também é uma classe de aplicação interativa e 
provavelmente a mais utilizada no momento em que este livro foi escrito. As aplicações de conferência 
multimídia baseadas na Internet, como dissemos no Capítulo 1 e ilustramos na Figura 1.1, oferecem 
outro exemplo. As aplicações modernas de mensagem instantânea também usam áudio e vídeo em 
tempo real. Estes são o tipo de aplicação com os requisitos de tempo real mais rigorosos. 

Aplicações de streaming normalmente oferecem fluxos de áudio ou vídeo de um servidor para um 
cliente, e são exemplificadas por produtos comerciais como RealAudio”. O streaming de vídeo, exem- 
plificado pelo YouTube, tornou-se uma das formas dominantes de tráfego na Internet. Devido à falta de 
interação humana, essas aplicações impõem requisitos diferentes sobre os protocolos subjacentes. Porém, 
a entrega em tempo ainda é importante — por exemplo, você deseja que um vídeo comece a ser exibido 
logo depois de apertar “play”, e quando ele começa a ser exibido, pacotes atrasados farão com que ele 
pare ou criarão algum tipo de degradação visual. Assim, embora as aplicações de streaming não sejam 
estritamente de tempo real, elas ainda têm bastante coisa em comum com as aplicações de multimídia 
interativas para justificar a consideração de um protocolo comum para os dois tipos de aplicação. 

A esta altura, deve estar claro que os projetistas de um protocolo de transporte para aplicações de 
multimídia enfrentam o desafio real de definir os requisitos com amplitude suficiente para atender às 
necessidades de aplicações muito diferentes. Eles também precisam prestar atenção às interações entre 
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FIGURA 5.21 Interface com o usuário de uma 
audioconferência com vat. 
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FIGURA 5.22 Pilha de protocolos para aplicações de multimídia usando RTP. 





diferentes aplicações; por exemplo, o sincronismo de fluxos de áudio e vídeo. Mais adiante, veremos 
como esses aspectos afetaram o projeto do principal protocolo de transporte de tempo real em uso 
atualmente, o RTP 

Grande parte do RTP na realidade, vem do protocolo de aplicação que estava embutido originalmente 
na própria aplicação. Quando a aplicação vat foi desenvolvida inicialmente, ela era executada sobre 
UDP e os projetistas descobriram quais recursos eram necessários para lidar com a natureza de tempo 
real da comunicação de voz. Mais tarde, eles observaram que esses recursos poderiam ser úteis para 
muitas outras aplicações e definiram um protocolo com esses recursos, que se tornou o RTP O RTP pode 
trabalhar em cima de muitos protocolos de camada inferior, mas normalmente trabalha em cima do 
UDP Isso leva à pilha de protocolos mostrada na Figura 5.22. Observe, portanto, que estamos executando 
um protocolo de transporte sobre um protocolo de transporte. Não existe regra contra isso, e de fato 
faz muito sentido, pois o UDP oferece um nível mínimo de funcionalidade, e a demultiplexação básica, 
baseada em números de porta, é exatamente o que o RTP precisa como ponto de partida. Assim, ao invés 
de recriar os números de porta no RTP o RTP “terceiriza” a função de demultiplexação para o UDP 


5.4.1 Requisitos 


O requisito mais básico para um protocolo de multimídia de uso geral é que ele permita a interope- 
rabilidade entre aplicações semelhantes. Por exemplo, deverá ser possível que duas aplicações de 


“Mas isso causou alguma confusão com relação a se o RTP é realmente um protocolo de transporte. 


276 REDES DE COMPUTADORES ELSEVIER 


audioconferência implementadas independentemente conversem entre si. Isso sugere imediatamente 
que é melhor a aplicação usar o mesmo método de codificação e compactação de voz; caso contrário, 
os dados transmitidos por uma parte serão incompreensíveis pela parte receptora. Como existem 
muitos esquemas de codificação diferentes para voz, cada um com suas próprias opções de qualidade, 
requisitos de largura de banda e custo computacional, provavelmente seria uma má ideia decretar que 
somente um esquema possa ser usado. Em vez disso, nosso protocolo precisa oferecer um meio de o 
transmissor poder dizer a um receptor qual esquema de codificação ele deseja usar, e possivelmente 
negociar até que seja identificado um esquema que esteja disponível a ambas as partes. 

Assim como o áudio, existem muitos esquemas de codificação de vídeo diferentes. Portanto, vemos 
que a primeira função comum que o RTP pode oferecer é a capacidade de comunicar essa escolha 
do esquema de codificação. Observe que isso também serve para identificar o tipo de aplicação (por 
exemplo, áudio ou vídeo); quando soubermos que algoritmo de codificação está sendo usado, também 
saberemos o tipo de dado que está sendo codificado. 

Outro requisito importante para o RTP é permitir que o destinatário de um fluxo de dados determine a 
relação de tempo entre os dados recebidos. Lembre-se, conforme veremos na Seção 6.5, que as aplicações 
de tempo real precisam colocar os dados recebidos em um buffer de reprodução, a fim de suavizar a 
flutuação de atraso (jitter) que pode ter sido introduzida no fluxo de dados durante a transmissão pela 
rede. Assim, algum tipo de carimbo de tempo dos dados será necessário para permitir que o receptor 
os reproduza no momento apropriado. 

Relacionado à temporização de um único fluxo de mídia está a questão de sincronismo de vários 
tipos de mídia em uma conferência. O exemplo óbvio disso seria sincronizar um fluxo de áudio e vídeo 
que esteja se originando do mesmo transmissor. Como veremos adiante, esse é um problema um pouco 
mais complexo do que a determinação do tempo de reprodução para um único fluxo. 

Outra função importante a ser oferecida é uma indicação da perda de pacotes. Observe que uma 
aplicação com requisitos estritos de latência geralmente não poderia usar um mecanismo de transporte 
confiável, como o TCP pois a retransmissão de dados para corrigir a perda provavelmente faria com que o 
pacote chegasse tarde demais para ser considerado útil. Assim, a aplicação precisa ser capaz de lidar com 
pacotes que são perdidos, e o primeiro passo para isso é notar que eles realmente estão faltando. Como 
um exemplo, uma aplicação de vídeo usando codificação MPEG precisará tomar ações diferentes quando 
um pacote for perdido, dependendo se o pacote veio de um quadro I, um quadro B ou um quadro P 

A perda de pacotes também é um indicador em potencial do congestionamento. Como as aplicações 
de multimídia geralmente não são executadas sobre TCP elas também perdem os recursos de prevenção de 
congestionamento dele (descritos na Seção 6.3). Mas muitas aplicações de multimídia são capazes 
de responder ao congestionamento; por exemplo, alterando os parâmetros do algoritmo de codificação 
a fim de reduzir a largura de banda consumida. Logicamente, para que isso funcione, o receptor precisa 
notificar ao transmissor que as perdas estão ocorrendo, para que ele possa ajustar seus parâmetros de 
codificação. 

Outra função comum entre aplicações de multimídia é o conceito de indicação da fronteira dos 
quadros. Um quadro, nesse contexto, é algo específico da aplicação. Por exemplo, pode ser útil notificar 
a uma aplicação de vídeo que certo conjunto de pacotes corresponde a um único quadro. Em uma 
aplicação de áudio, seria útil marcar o início de uma “rajada de fala”, que é uma coleção de sons ou pala- 
vras, seguida de silêncio. O receptor pode, então, identificar os silêncios entre as rajadas de fala e usá-los 
como oportunidades para mover o ponto de reprodução. Isso segue a observação de que encurtar ou 
estender ligeiramente os espaços entre as palavras não é perceptível aos usuários, enquanto encurtar 
ou estender as palavras em si é tanto perceptível como incômodo. 

Uma última função que poderíamos querer colocar no protocolo é algum meio de identificar emis- 
sores que seja mais amigável do que um endereço IP Conforme ilustramos na Figura 5.21, as aplicações 
de conferência de áudio e vídeo podem exibir sequências de caracteres como Usuário João (usuario? 
dominio.com) em seus painéis de controle, e com isso o protocolo de aplicação precisa dar suporte à 
associação de tal sequência de caracteres a um fluxo de dados. 

Além da funcionalidade que é necessária em nosso protocolo, observamos um requisito adicional. Ele 
deve fazer uso da largura de banda de forma razoavelmente eficiente. Em outras palavras, não queremos 
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introduzir muitos bits extras que tenham de ser enviados com cada pacote na forma de um cabeça- 
lho longo. O motivo para isso é que os pacotes de áudio, que são um dos tipos mais comuns de dados 
multimídia, costumam ser pequenos, a fim de reduzir o tempo gasto para preenchê-los com amostras. 
O uso de longos pacotes de áudio significaria alta latência, devido ao empacotamento, que apresenta 
um efeito negativo sobre a qualidade perceptível das conversas. (Lembre-se que esse foi um dos fatores 
para a escolha do tamanho das células ATM.) Como os pacotes de dados em si são curtos, um cabeçalho 
grande significaria que uma quantidade relativamente grande da largura de banda do enlace seria usada 
por cabeçalhos, reduzindo assim a capacidade disponível para os dados “úteis”. Veremos vários aspectos 
do projeto do RTP que foram influenciados pela necessidade de manter o cabeçalho curto. 

Você poderia se perguntar se cada recurso isolado que descrevemos realmente precisa estar em um 
protocolo de transporte de tempo real, e provavelmente poderia levantar alguns outros que poderiam 
ser acrescentados. A ideia básica aqui é tornar a vida mais fácil para os desenvolvedores de aplicação, 
dando-lhes um conjunto de abstrações e blocos construtivos úteis para suas aplicações. Por exemplo, 
colocando um mecanismo de carimbo de tempo no RTP evitamos que o desenvolvedor de uma aplicação 
de tempo real invente seu próprio mecanismo. Também aumentamos as chances de que duas aplicações de 
tempo real diferentes possam interoperar. 


5.4.2 Detalhes do RTP 


Agora que você já viu a lista um tanto longa de requisitos do nosso protocolo de transporte para multi- 
mídia, vejamos os detalhes do protocolo que foram especificados para atender a esses requisitos. Este 
protocolo, o RTP foi desenvolvido na IETF e está sendo muito utilizado. O padrão RTP na realidade, 
define um par de protocolos: o RTP e o protocolo de controle de transporte em tempo real (RTCP — 
Real-time Transport Control Protocol). O primeiro é usado para a troca de dados multimídia, enquanto 
o outro é usado para enviar periodicamente informações de controle associadas a certo fluxo de dados. 
Ao executar sobre UDP o fluxo de dados RTP e o fluxo de controle RTCP associado utilizam portas 
consecutivas da camada de transporte. Os dados RTP utilizam um número de porta par e as informações 
de controle RTCP utilizam o número de porta que vem logo em sequência (ímpar). 

Como o RTP foi projetado para dar suporte a uma grande variedade de aplicações, ele oferece um 
mecanismo flexível, pelo qual novas aplicações possam ser desenvolvidas sem revisar repetidamente o 
próprio protocolo RTP Para cada classe de aplicação (por exemplo, áudio), o RTP define um perfil e um 
ou mais formatos. O perfil oferece uma série de informações que garantem um conhecimento comum 
dos campos no cabeçalho RTP para essa classe de aplicação, como ficará claro quando examinarmos 
o cabeçalho com detalhes. A especificação de formato explica como os dados após o cabeçalho RTP 
devem ser interpretados. Por exemplo, o cabeçalho RTP poderia simplesmente ser acompanhado de 
uma sequência de bytes, cada um representando uma única amostra de áudio tomada em um intervalo 
definido, após a sequência anterior. Alternativamente, o formato dos dados poderia ser muito mais 
complexo; um fluxo de vídeo codificado com MPEG, por exemplo, precisaria ter uma estrutura com- 
plexa para representar todos os diferentes tipos de informação. 


O projeto do RTP incorpora um princípio arquitetônico conhecido como enquadramento no nível da 
aplicação (ALF — Application Level Framing). Esse princípio foi apresentado por Clark e Tennenhouse, 

em 1990, como um meio de projetar protocolos para as aplicações de multimídia emergentes. Eles 
reconheceram que essas novas aplicações provavelmente não seriam muito bem atendidas pelos protocolos 
existentes, como TCP e que além disso elas poderiam não ser bem atendidas por qualquer outro protocolo 
do tipo “um tamanho para tudo”. No coração desse princípio está a convicção de que uma aplicação entende 


melhor suas próprias necessidades. Por exemplo, uma aplicação de vídeo MPEG sabe como se recuperar 
melhor de quadros perdidos, e como reagir de forma diferente se um quadro I ou um quadro B for perdido. 
A mesma aplicação também entende melhor como segmentar os dados para a transmissão — por exemplo, é 
melhor transmitir os dados de diferentes quadros em diferentes datagramas, para que um pacote perdido só 
afete um único quadro, e não dois. É por esse motivo que o RTP deixa muitos dos detalhes do protocolo para 
os documentos de perfil e formato, que são específicos de uma aplicação. 
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Formato de cabeçalho 

A Figura 5.23 mostra o formato de cabeçalho usado pelo RTP Os 12 primeiros bytes estão sempre pre- 
sentes, enquanto os identificadores de fonte contribuinte são usados apenas em certas circunstâncias. 
Após esse cabeçalho pode haver extensões de cabeçalho opcionais, conforme descrevemos a seguir. 
Finalmente, o cabeçalho é seguido pela carga útil do RTP cujo formato é determinado pela aplicação. 
A intenção desse cabeçalho é que ele contenha apenas os campos que provavelmente serão usados por 
muitas aplicações diferentes, pois qualquer coisa muito específica a uma única aplicação seria trans- 
portada de modo mais eficiente na carga útil RTP para essa aplicação especificamente. 

Os dois primeiros bits são um identificador de versão, que contém o valor 2 na versão do RTP em uso 
no momento em que este livro foi escrito. Você poderia pensar que os projetistas do protocolo foram 
um tanto corajosos ao pensar que 2 bits seriam suficientes para conter todas as versões futuras do RTP 
mas lembre-se que os bits são escassos em um cabeçalho RTP Além disso, o uso de perfis para diferentes 
aplicações torna menos provável que sejam necessárias muitas revisões do protocolo RTP básico. De 
qualquer forma, se outra versão do RTP for necessária além da versão 2, seria possível considerar uma 
mudança no formato do cabeçalho, para que mais de uma versão futura seja possível. Por exemplo, 
um novo cabeçalho RTP com o valor 3 no campo de versão poderia ter um campo de “subversão” em 
algum outro lugar no cabeçalho. 

O bit seguinte é o bit de padding, ou preenchimento (P), que é marcado em circunstâncias em que a 
carga útil RTP foi preenchida por algum motivo. Os dados RTP poderiam ser preenchidos a fim de com- 
pletar um bloco de certo tamanho, conforme exigido por um algoritmo de criptografia, por exemplo. 
Nesse caso, o tamanho completo do cabeçalho RTP, dados e preenchimento seria transportado pelo 
cabeçalho do protocolo da camada inferior (por exemplo, o cabeçalho UDP), e o último byte do preen- 
chimento teria uma contagem de quantos bytes devem ser ignorados. Isso é ilustrado na Figura 5.24. 
Observe que essa técnica de preenchimento remove qualquer necessidade de um campo de tamanho 
no cabeçalho RTP (atendendo assim ao objetivo de manter o cabeçalho curto); no caso comum de ne- 
nhum preenchimento, o tamanho é deduzido a partir do protocolo da camada inferior. 

O bit de extensão (X) é usado para indicar a presença de um cabeçalho de extensão, que seria definido 
para uma aplicação específica e vem após o cabeçalho principal. Esses cabeçalhos raramente são usados, 
pois geralmente é possível definir um cabeçalho específico da carga útil como parte da definição do 
formato da carga útil para uma aplicação específica. 

O bit X é seguido por um campo de 4 bits (CC) que conta o número de fontes contribuintes, se houver 
alguma incluída no cabeçalho. As fontes contribuintes são discutidas mais adiante. 


V=2| P| X|CC| M| PT Número de sequência 
Carimbo de tempo 
ID de fonte de sincronismo (SSRC) 


IDs de fonte contribuinte (CSRC) 


Cabeçalho de extensão 


Carga útil RTP 
FIGURA 5.23 Formato do cabeçalho RTP. 
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FIGURA 5.24 Preenchimento de um pacote RTP. 
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Já observamos anteriormente a necessidade frequente de algum tipo de indicação de fronteiras de 
quadro; isso é fornecido pelo bit de marcação, que poderia ser colocado em 1 no início de uma rajada 
de fala, por exemplo. O campo de tipo de carga útil (TCU) com 7 bits vem em seguida; ele indica que 
tipo de dados multimídia é transportado nesse pacote. Um uso possível desse campo seria para permitir 
que uma aplicação trocasse de um esquema de codificação para outro com base na informação sobre 
a disponibilidade de recursos na rede ou no feedback sobre a qualidade da aplicação. O uso exato do 
bit de marcação e do tipo de carga útil é determinado pelo perfil de aplicação. 

Observe que o tipo de carga útil geralmente não é usado como uma chave de demultiplexação para 
direcionar dados a diferentes aplicações (ou a diferentes fluxos dentro de uma única aplicação, por 
exemplo, os fluxos de áudio e vídeo para uma videoconferência). Isso porque tal demultiplexação nor- 
malmente é fornecida em uma camada inferior (por exemplo, pelo UDP conforme descrito na Seção 5.1). 
Assim, dois fluxos de mídia usando RTP normalmente usariam números de porta UDP diferentes. 

O número de sequência é usado para permitir que o receptor de um fluxo RTP detecte pacotes per- 
didos ou desordenados. O emissor simplesmente incrementa o valor em 1 para cada pacote transmitido. 
Observe que o RTP não faz nada quando detecta um pacote perdido, ao contrário do TCP que corrige a 
perda (por meio de retransmissão) e a interpreta como uma indicação de congestionamento (o que pode 
fazer com que ele reduza seu tamanho de janela). Em vez disso, fica a critério da aplicação decidir o que 
fazer quando um pacote é perdido, pois essa decisão provavelmente dependerá muito da aplicação. Por 
exemplo, uma aplicação de vídeo pode decidir que a melhor coisa a fazer quando um pacote é perdido 
é reproduzir o último quadro que foi recebido corretamente. Algumas aplicações também poderiam 
decidir modificar seus algoritmos de codificação para reduzir as necessidades de largura de banda em 
resposta à perda, mas essa não é uma função do RTP Não seria sensato para o RTP decidir que a taxa 
de envio deve ser reduzida, pois isso poderia tornar a aplicação inútil. 

A função do campo de carimbo de tempo é permitir que o receptor reproduza amostras em intervalos 
apropriados e permitir que diferentes fluxos de mídia sejam sincronizados. Como aplicações diferentes 
podem exigir diferentes granularidades de temporização, o próprio RTP não especifica as unidades em 
que o tempo é medido. Em vez disso, o carimbo de tempo é apenas um contador de “tics” de relógio, 
onde o tempo entre tics depende da codificação em uso. Por exemplo, uma aplicação de áudio que 
captura amostras de dados a cada 125 us poderia usar esse valor como sua resolução de relógio. A 
granularidade do relógio é um dos detalhes que é especificado no perfil ou formato de carga útil RTP 
para uma aplicação. 

O valor do carimbo de tempo no pacote é um número representando a hora em que a primeira 
amostra no pacote foi gerada. O carimbo de tempo não é um reflexo desse horário; apenas as diferenças 
entre os carimbo de tempo são relevantes. Por exemplo, se o intervalo de amostragem for 125us e a 
primeira amostra no pacote n + 1 foi gerada 10 ms após a primeira amostra no pacote n, então o número 
de instantes de amostragem entre essas duas amostras é: 


TempoEntrePacotes  TempoPorAmostra = (10 x 10-3) + (125 x 108) 
=80 


Supondo que a granularidade do relógio seja a mesma do intervalo de amostragem, então o carimbo 
de tempo no pacote n+ 1 seria 80 a mais do que no pacote n. Observe que menos de 80 amostras pode- 
riam ter sido enviadas, devido a técnicas de compactação como detecção de silêncio, e mesmo assim 
o carimbo de tempo permite que o receptor reproduza as amostras com o relacionamento temporal 
correto. 

A fonte de sincronismo (SSRC) é um número de 32 bits que identifica univocamente uma única 
fonte de um fluxo RTP Em uma conferência de multimídia, cada emissor escolhe uma SSRC aleatória e 
espera-se que ele resolva conflitos no evento improvável de que duas fontes escolham o mesmo valor. 
Ao tornar o identificador da origem algo diferente do endereço de rede ou de transporte da origem, o 
RTP garante independência do protocolo de nível inferior. Isso também permite que um único nó com 
várias fontes (por exemplo, várias câmeras) diferencie essas fontes. Quando um único nó gera diferentes 
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fluxos de mídia (por exemplo, áudio e vídeo), não é necessário usar a mesma SSRC em cada fluxo, pois 
existem mecanismos no RTCP (descrito a seguir) para permitir sincronismo entre as mídias. 

A fonte contribuinte (CSRC) é usada apenas quando uma série de fluxos RTP passa por um mixer 
(misturador). Um mixer pode ser usado para reduzir os requisitos de largura de banda em uma confe- 
rência, recebendo dados de muitas origens e enviando-os como um único fluxo. Por exemplo, os fluxos 
de áudio de vários oradores simultâneos poderiam ser decodificados e recodificados como um único 
fluxo de áudio. Nesse caso, o mixer é listado como fonte de sincronismo, mas também lista as fontes 
contribuintes — os valores de SSRC dos oradores que contribuíram para o pacote em questão. 


5.4.3 Protocolo de controle 


O RTCP oferece um fluxo de controle que está associado a um fluxo de dados para uma aplicação de 
multimídia. Esse fluxo de controle oferece três funções principais: 


1. Feedback sobre o desempenho da aplicação e da rede. 

2. Um modo de correlacionar e sincronizar diferentes fluxos de mídia que vieram do mesmo 
emissor. 

3. Um modo de transportar a identidade de um emissor para exibir em uma interface com o usuário 
(por exemplo, a interface do vat aparece na Figura 5.21). 


A primeira função pode ser útil para detectar e responder ao congestionamento. Algumas aplicações 
são capazes de operar em diferentes taxas, podendo utilizar dados de desempenho para decidir usar um 
esquema de compactação mais agressivo para reduzir o congestionamento, por exemplo, ou para enviar 
um fluxo de qualidade mais alta quando existe pouco congestionamento. O feedback do desempenho 
também pode ser útil no diagnóstico de problemas da rede. 

Você poderia pensar que a segunda função já é fornecida pelo identificador de fonte de sincronismo 
do RTP (SSRC), mas na verdade não é. Como já observamos, várias câmeras de um único nó poderiam 
ter valores de SSRC diferentes. Além disso, não existe o requisito de que um fluxo de áudio e vídeo do 
mesmo nó use a mesma SSRC. Como as colisões de valores de SSRC podem ocorrer, pode ser necessário 
mudar o valor de SSRC de um fluxo. Para lidar com esse problema, o RTCP usa o conceito de um nome 
canônico (CNAME) que é atribuído a um emissor, o qual é associado aos diversos valores de SSRC que 
poderiam ser usados por esse emissor usando mecanismos do RTCP. 

A simples correlação de dois fluxos é apenas parte do problema do sincronismo entre mídias. Como 
diferentes fluxos podem ter relógios completamente diferentes (com granularidades diferentes e até mes- 
mo diferentes quantidades de imprecisão, ou tendência a atrasar /adiantar), é preciso haver um meio de 
sincronizar com precisão os fluxos entre si. O RTCP resolve esse problema transmitindo informações 
de temporização que relacionam a hora real do dia com os carimbos de tempo dependentes da taxa de 
relógio que são transportados nos pacotes de dados RTP 

O RTCP define uma série de tipos de pacote diferentes, incluindo: 


e Relatórios de emissor, que permitem que emissores ativos em uma sessão informem estatísticas 
de transmissão e recepção. 

e Relatórios de receptor, que os receptores que não são emissores utilizam para informar estatísticas 
de recepção. 

e Descrições de origem, que transportam CNAMES e outras informações de descrição do emissor. 

e Pacotes de controle específicos da aplicação. 


Esses diferentes tipos de pacotes RTCP são enviados pelo protocolo da camada inferior, o qual, como 
já dissemos, normalmente é o UDP Vários pacotes RTCP podem ser empacotados em uma única PDU do 
protocolo de nível inferior. É preciso que pelo menos dois pacotes RTCP sejam enviados em cada PDU 
do nível inferior. Um deles é um pacote de relatório; o outro é um pacote de descrição da origem. Outros 
pacotes podem ser incluídos, até os limites de tamanho impostos pelos protocolos da camada inferior. 

Antes de examinar de perto o conteúdo de um pacote RTCP observamos que existe um problema 
em potencial com cada membro de um grupo de multicast enviando tráfego de controle periódico. A 
menos que tomemos algumas medidas para limitar isso, esse tráfego de controle tem o potencial de 
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se tornar um consumidor significativo da largura de banda. Por exemplo, em uma audioconferência, 
apenas dois ou três emissores provavelmente enviam dados de áudio em determinado instante, pois 
não há sentido em todos falarem ao mesmo tempo. Mas não existe um limite social que previna que 
todos eles enviem tráfego de controle, e isso poderia ser um problema sério em uma conferência com 
milhares de participantes. Para resolver esse problema, o RTCP possui um conjunto de mecanismos 
pelos quais os participantes reduzem sua frequência de envio de relatórios à medida que o número 
de participantes aumenta. Essas regras são um tanto complexas, mas o objetivo básico é este: limitar 
a quantidade total de tráfego RTCP a uma porcentagem pequena (normalmente 5%) do tráfego de 
dados RTP Para atingir esse objetivo, os participantes devem saber quanta largura de banda para dados 
provavelmente está sendo usada (por exemplo, a quantidade usada para enviar três fluxos de áudio) 
e o número de participantes. Eles descobrem o primeiro por meio de mecanismos externos ao RTP 
(conhecidos como gerenciamento de sessão, discutidos ao final desta seção), e descobrem o segundo 
por meio de relatórios RTCP de outros participantes. Como os relatórios RTCP podem ser enviados em 
uma taxa muito baixa, pode ser possível obter apenas uma contagem aproximada do número atual de 
destinatários, mas isso normalmente é o suficiente. Além disso, recomenda-se alocar mais largura de 
banda RTCP para emissores ativos, supondo que a maioria dos participantes gostaria de ver os relatórios 
deles, por exemplo, para descobrir quem está falando. 

Quando um participante tiver determinado quanta largura de banda ele pode consumir com tráfego 
RTCP ele começa a enviar relatórios periódicos na taxa apropriada. Os relatórios do emissor e do receptor 
são diferentes apenas porque o primeiro inclui alguma informação extra sobre o emissor. Os dois tipos 
de relatórios contêm informações sobre os dados que foram recebidos de todas as origens no período de 
relatório mais recente. 

A informação extra em um relatório do emissor consiste em: 


e Um carimbo de tempo contendo a hora do dia real em que esse relatório foi gerado. 

e O carimbo de tempo RTP correspondente à hora em que o relatório foi gerado. 

e Contadores acumulados dos pacotes e bytes enviados por esse emissor desde que ele iniciou a 
transmissão. 


Observe que as duas primeiras quantidades podem ser usadas para permitir o sincronismo de dife- 
rentes fluxos de mídia provenientes da mesma origem, mesmo que esses fluxos usem granularidades 
de relógio diferentes em seus fluxos de dados RTP pois ele oferece a chave para converter a hora do dia 
para os carimbos de tempo RTP 

Os relatórios do emissor e do receptor contêm ambos um bloco de dados por fonte que foi ouvida 
desde o último relatório. Cada bloco contém as seguintes estatísticas relativas à fonte em questão: 


e Sua SSRC. 

e A fração dos pacotes de dados dessa fonte que foram perdidos desde que o último relatório foi 
enviado (calculada comparando-se o número de pacotes recebidos com o número de pacotes 
esperados; esse último valor pode ser determinado a partir dos números de sequência do RTP). 

e Número total de pacotes perdidos dessa fonte desde a primeira vez em que ela foi ouvida. 

e Maior número de sequência recebido dessa fonte (estendido para 32 bits para levar em 
consideração o reinício do número de sequência). 

e Flutuação estimada entre as chegadas para essa fonte (calculada comparando-se o espaçamento 
entre chegadas dos pacotes recebidos com o espaçamento esperado no momento da 
transmissão). 

e Último carimbo de tempo recebido via RTCP para essa fonte. 

e Atraso desde o último relatório de emissor recebido por RTOP para essa fonte. 


Como você poderia imaginar, os destinatários dessa informação podem descobrir todo tipo de coisa 
sobre o estado da sessão. Em particular, eles podem ver se outros destinatários estão obtendo qualidade 
muito melhor de algum emissor do que eles próprios estão, o que poderia ser uma indicação de que 
precisa ser feita uma reserva de recursos, ou que existe um problema na rede que precisa de atenção. 
Além disso, se um emissor notar que muitos receptores estão experimentando uma grande perda de 
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seus pacotes, ele pode decidir que precisa reduzir sua taxa de envio ou usar um esquema de codificação 
que seja mais tolerante a perdas. 

O aspecto final do RTCP que consideraremos é o pacote de descrição de origem. Esse pacote contém, 
no mínimo, a SSRC da fonte e o CNAME do emissor. O nome canônico é derivado de tal forma que todas 
as aplicações que geram fluxos de mídia que possam precisar de sincronismo (por exemplo, fluxos de 
áudio e vídeo gerados separadamente a partir do mesmo usuário) escolherão o mesmo CNAME, embora 
pudessem escolher valores de SSRC diferentes para cada fonte. Isso permite que um receptor identifique 
o fluxo de mídia que veio do mesmo emissor. O formato mais comum do CNAME é usuario O host, 
onde host é o nome de domínio totalmente qualificado da máquina emissora. Assim, uma aplicação 
iniciada pelo usuário cujo nome de usuário é jsilva executando na máquina cicada.cs.princeton.edu 
usaria a cadeia de caracteres jsilva O cicada.es.princeton.edu como seu CNAME. O número grande e 
variável de bytes usados nessa representação a tornaria uma má escolha para o formato de uma SSRC, 
pois a SSRC é enviada com cada pacote e precisa ser processada em tempo real. Permitir que CNAMESs 
sejam vinculados a valores de SSRC em mensagens RTCP periódicas possibilita um formato compacto 
e eficiente para a SSRC. 

Outros itens podem ser incluídos no pacote de descrição da origem, como o nome real e o endereço 
de correio eletrônico do usuário. Estes são usados nas telas da interface com o usuário e para o contato 
com participantes, mas são menos essenciais para a operação do RTP do que o CNAME. 

Assim como o TCP o RTP e o RTCP são um par de protocolos muito complexos. Essa complexidade 
vem em grande parte do desejo de tornar a vida mais fácil para os projetistas de aplicação. Como 
existe um número infinito de aplicações possíveis, o desafio no projeto de um protocolo de transporte 
é torná-lo genérico o bastante para atender as necessidades bastante variadas de muitas aplicações, 
sem tornar o próprio protocolo impossível de implementar. O RTP provou ser muito bem sucedido 
em relação a isso, formando a base para a maioria das comunicações de multimídia em tempo real via 
Internet nos dias de hoje. 


5.5 Resumo 


Este capítulo descreveu três protocolos fim a fim muito diferentes. O primeiro protocolo que conside- 
ramos é um demultiplexador simples, representado pelo UDP Tudo o que um protocolo desse tipo faz 
é despachar mensagens para o processo de aplicação apropriado, com base em um número de porta. 
Ele não melhora o modelo de serviço de melhor esforço da rede subjacente de forma alguma ou, em 
outras palavras, ele oferece um serviço de datagrama não confiável e sem conexões para os programas 
de aplicação. 

O segundo tipo é um protocolo de fluxo de bytes confiável, e o exemplo específico que examinamos 
para esse tipo é o TCP. Os desafios enfrentados por tal protocolo são recuperar-se de mensagens que 
possam ter sido perdidas pela rede, entregar mensagens na mesma ordem em que são enviadas e per- 
mitir que o receptor realize controle de fluxo sobre o emissor. O TCP utiliza o algoritmo básico de janela 
deslizante, melhorado com uma janela anunciada, para implementar essa funcionalidade. O outro item 
a ser observado para esse protocolo é a importância de um mecanismo preciso de expiração de tempo 
limite/retransmissão. É interessante que, embora o TCP seja um único protocolo, vimos que ele emprega 
pelo menos cinco algoritmos diferentes — janela deslizante, Nagle, three-way handshake, Karn/Partridge 
e Jacobson/Karels —, todos podendo ser valiosos para qualquer protocolo fim a fim. 

O terceiro protocolo de transporte que examinamos é um protocolo de solicitação/resposta que 
forma a base para o RPC. Esses protocolos precisam despachar solicitações para os procedimentos 
remotos corretos e ligar as respostas às solicitações correspondentes. Eles também podem oferecer 
confiabilidade, como a semântica “no máximo uma vez”, ou dar suporte a tamanhos de mensagens 
grandes pela fragmentação e remontagem de mensagens. 

Por fim, examinamos os protocolos de transporte para a classe de aplicações que envolvem dados 
de multimídia (como áudio e vídeo) e que possuem um requisito de entrega em tempo real. Esse 
protocolo de transporte precisa oferecer ajuda com a recuperação de informações de temporização 
de um único fluxo de mídia e com o sincronismo de vários fluxos de mídia. Ele também precisa prover 
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informações para as camadas superiores (por exemplo, a camada de aplicação) sobre dados perdidos 
(pois normalmente não haverá tempo suficiente para retransmitir pacotes perdidos), de modo que 
métodos apropriados de recuperação e prevenção de congestionamento específicos da aplicação possam 
ser empregados. O protocolo que foi desenvolvido para atender a essas necessidades é o RTP que inclui 
um protocolo de controle que lhe acompanha chamado RTCP. 


E E O que vem em seguida: Diversidade do protocolo de transporte E 


O que deverá estar claro após a leitura deste capítulo é que o projeto do protocolo de transporte é 
uma tarefa intricada. Como vimos, criar um protocolo de transporte correto em primeiro lugar já 
é muito difícil, enquanto as circunstâncias mutáveis tornam as coisas mais complicadas. Algumas 
mudanças não são difíceis de prever — as redes continuam se tornando mais rápidas, por exemplo —, 
mas, às vezes, uma nova classe de aplicações aparece e muda os requisitos dos serviços no nível de 
transporte. O desafio é encontrar maneiras de se adaptar a essas mudanças. Às vezes, os protocolos 
existentes podem ser modificados para lidar com novas circunstâncias — as opções do TCP evoluíram 
com o tempo para conseguir isso —, outras vezes pode ser preciso criar um novo protocolo de trans- 
porte, assim como o RTP e o SCTP Não sabemos ao certo quando devemos reutilizar um protocolo 
existente ou criar um novo. 

Além de fazer pequenas mudanças em um protocolo existente para acomodar os ambientes de 
rede em mutação ou as novas necessidades da aplicação, às vezes poderíamos ser capazes de mo- 
dificar a aplicação para que ela funcione com um protocolo existente. Por exemplo, uma aplicação 
que precisa de semântica de RPC provavelmente funcionaria melhor com um protocolo RPC, mas 
com um pouco de trabalho e alguma perda de eficiência, ela pode usar TCP Vemos isso acontecendo 
muito hoje em dia quando aplicações baseadas na Web precisam de algum tipo de RPC. O TCP é 
onipresente na Web e conhecido por funcionar em todos os tipos de ambientes desafiadores, como 
através de dispositivos NAT e firewalls. Consequentemente, às vezes é mais simples criar mecanismos 
tipo RPC que são executados em cima do TCP (e do HTTP em muitos casos), mesmo que essa não 
seja estritamente a técnica mais eficiente. 

De modo semelhante, parece que o RTP deve ser o protocolo escolhido para o streaming de 
vídeo, e continua a ser bastante utilizado, mas há também uma grande tendência para o uso de TCP 
(e HTTP) para entregar conteúdo de streaming de vídeo. Essa técnica é cada vez mais popular para 
a entrega de vídeo de entretenimento, como shows de TV e filmes, para exibição em navegadores 
Web. É muito cedo para sabermos como tudo isso acabará, mas não é difícil imaginar um futuro em 
que o TCP será o protocolo de transporte dominante para entrega de vídeo. 

Retornando à arquitetura de “ampulheta” da Internet, que discutimos no Capítulo 1, fica evidente que 
alguma diversidade dos protocolos de transporte era esperada pelos projetistas da Internet. Porém, neste 
ponto na história da Internet, praticamente parece que o próprio TCP pode se tornar parte da cintura 
da ampulheta, oferecendo o serviço onipresente do qual a maior parte das aplicações dependerá. 


Leitura adicional 


Não há dúvida de que TCP é um protocolo complexo e que realmente possui sutilezas não esclarecidas neste capítulo. 

Portanto, a lista de leitura recomendada para este capítulo inclui a especificação do TCP original. Nossa motivação para 

incluir essa especificação não é tanto preencher os detalhes que faltam, mas expor o conteúdo de uma especificação 

de protocolo confiável. O artigo seguinte, de Birrel e Nelson, é a origem do assunto de RPC. O terceiro, o artigo de Clark 

e Tennenhouse sobre arquitetura de protocolo, introduziu o conceito de enquadramento na camada de aplicação, que 

inspirou o projeto do RTP; esse artigo fornece uma visão considerável sobre os desafios de projetar protocolos à medida 

que as necessidades da aplicação mudam. 

USC-ISI. Transmission Control Protocol. Request for Comments 793, setembro de 1981. 

Birrell, A.; Nelson, B. Implementing remote procedure calls. ACM Transactions on Computer Systems, v. 2, n. 1, p. 39-59, 
fevereiro de 1984. 

Clark, D.; Tennenhouse, D. Architectural considerations for a new generation of protocols. Proceedings of the SIGCOMM 
90 Symposium, p. 200-8, setembro de 1990. 
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Além da especificação do protocolo, a descrição mais completa do TCP incluindo sua implementação 
no Unix, pode ser encontrada em Stevens [Ste94], [SW95]. Além disso, o terceiro volume da série 
de livros sobre TCP/IP de Comer e Stevens explica como escrever aplicações cliente/servidor em cima de 
TCP e UDP usando a interface de sockets Posix [CS00], a interface de sockets do Windows [CS97] e a 
interface de sockets do BSD [CS96]. O SCTP um protocolo de transporte confiável que ataca um ponto 
diferente do TCP no domínio de projetos, é descrito no interessante [0Y02], que fornece uma visão 
geral, e é especificado em [Ste07]. 

Diversos artigos avaliam o desempenho de diferentes protocolos de transporte em um nível bas- 
tante detalhado. Por exemplo, o artigo de Clark et al. [CJRS89] mede os overheads de processamento do 
TCP um artigo de Mosberger et al. [MPBO96] explora as limitações dos overheads de processamento 
do protocolo, e Thekkath e Levy [TL93] e Schroeder e Burrows [SB89] examinam o desempenho do RPC 
com muitos detalhes. 

O cálculo de tempo limite de expiração original do TCP é descrito na especificação do TCP (ver citação 
anterior), enquanto o algoritmo de Karn/Partridge é descrito em [KP91] e o algoritmo de Jacobson/Karels 
foi proposto em [Jac88]. As extensões do TCP são definidas por Jacobson et. al. [JBB92], enquanto 
O'Malley e Peterson [OP91] argumentam que extender o TCP dessa maneira não é a abordagem correta 
para solucionar o problema. 

Vários sistemas operacionais distribuídos definiram seu próprio protocolo de RPC. Alguns exemplos 
notáveis incluem o sistema V, descrito por Cheriton e Zwaenepoel [CZ85]; Sprite, descrito por Ousterhout 
et al. [OCD*88]; e Amoeba, descrito por Mullender [Mul90]. 

O RTP é descrito no RFC 3550 [SCFJ03], e existem diversos outros RFCs (como o RFC 3551 [SC03]) 
que descrevem os perfis de várias aplicações que utilizam RTP McCanne e Jacobson [MJ95] descrevem 
o vic, uma das primeiras aplicações de vídeo a usar RTP 

Por fim, a referência viva a seguir fornece muitas informações relacionadas a protocolos de trans- 
porte e outros: 


e hitp:/Avww.iana.org/protocols/: Informações sobre todas as opções, constantes, números de porta 
etc., que foram definidos para diversos protocolos da Internet. Você poderá encontrar aqui, 
entre outras coisas, as listas de flags de cabeçalho TCP opções do TCP e números de porta bem 
conhecidos para os protocolos que trabalham em cima de TCP e UDP. 


Exercícios 


1. Se um datagrama UDP for enviado do host A, na porta P para o host B, na porta Q, mas no host 
B não houver um processo escutando na porta Q, então B deve enviar de volta uma mensagem 
ICMP de Port Unreachable (porta inalcançável) para A. Assim como todas as mensagens ICMP, 
esta é endereçada a A como um todo, e não à porta P de A. 

a. Dê um exemplo de quando uma aplicação poderia querer receber tais mensagens ICMP. 

b. Descubra o que uma aplicação precisa fazer, no sistema operacional à sua escolha, para 
receber tais mensagens. 

c. Por que pode não ser uma boa ideia enviar tais mensagens diretamente de volta à porta P de 
origem em A? 

2. Considere um protocolo simples baseado no UDP para solicitar arquivos (informalmente baseado 
no Trivial File Transport Protocol, TFTP). O cliente envia uma solicitação de arquivo inicial, e o 
servidor responde (se o arquivo puder ser enviado) com o primeiro pacote de dados. Cliente e 
servidor, então, comtinuam a comuninação com um mecanismo de transmissão do tipo parar e 
esperar. 

a. Descreva um cenário no qual um cliente poderia solicitar um arquivo mas receber outro; você 
pode permitir que a aplicação cliente seja fecha bruscamente e seja reiniciada com a mesma 
porta. 

b. Proponha uma mudança no protocolo para tornar essa situação muito menos provável. 





3. 


“10. 


11. 


12. 
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Projete um protocolo simples baseado no UDP para obter arquivos de um servidor. Nenhuma 

autenticação precisa ser fornecida. A transmissão de dados do tipo parar e esperar pode ser 

utilizada. Seu protocolo deverá resolver as seguintes questões: 

a. A duplicação do primeiro pacote não deverá duplicar a “conexão”. 

b. A perda do ACK final não necessariamente deverá deixar o servidor em dúvida sobre se a 
transferência teve sucesso ou não. 

c. Um pacote que chega atrasado de uma conexão passada não deverá ser interpretável como 
parte da conexão atual. 

Este capítulo explica três sequências de transições de estado durante o encerramento da 

conexão TCP Há uma quarta sequência possível, que atravessa um arco adicional (não mostrado 

na Figura 5.7) de FIN WAIT 1 para TIME WATT e rotulado como FIN +ACK/ACK. Explique as 

circunstâncias que resultam nessa quarta sequência de encerramento. 


. Ao fechar uma conexão TCP por que a expiração do tempo limite de dois tempos de vida do 


segmento não é necessária na transição de LAST ACK para CLOSED? 

Um emissor em uma conexão TCP que recebe uma janela anunciada 0 sonda o receptor 
periodicamente para descobrir quando a janela se torna diferente de zero. Por que o receptor 
precisaria de um temporizador extra se ele fosse responsável por informar que sua janela 
anunciada se tornou diferente de 0 (ou seja, se o transmissor não fizesse a sondagem)? 

Leia a página obtida via comando man (ou o comando equivalente no Windows) para o utilitário 
netstat do Unix/Windows. Use o netstat para ver o estado das conexões TCP locais. Descubra 
quanto tempo as conexões gastam em TIME WAIT. 

O campo de número de sequência no cabeçalho TCP tem 32 bits de extensão, que é grande o 
suficiente para cobrir mais de 4 bilhões de dados. Mesmo que todos esses bytes nunca sejam 
transferidos em uma única conexão, por que o número de sequência ainda pode se reiniciar 
ciclicamente de 23 — 1 para 0? 


. Você foi encarregado de projetar um protocolo de fluxo de bytes confiável que use janela 


deslizante (como o TCP). Esse protocolo será executado em uma rede de 100 Mbps. O RTT da 

rede é de 100 ms, e o tempo de vida máximo dos segmentos é de 30 segundos. 

a. Quantos bits você incluiria nos campos JanelaAnunciada e NúmeroSeg do cabeçalho do seu 
protocolo? 

b. Como você determinaria esses números, e quais valores poderiam ser menos certos? 

Você foi encarregado de projetar um protocolo de fluxo de bytes confiável que use janela 

deslizante (como o TCP). Esse protocolo será executado em uma rede de 1 Gbps. O RTT da rede 

é de 140 ms, e o tempo de vida máximo dos segmentos é de 60 segundos. Quantos bits você 

incluiria nos campos JanelaAnunciada e NúmeroSeg do cabeçalho do seu protocolo? 

Suponha que um host queira determinar a confiabilidade de um enlace enviando pacotes e 

medindo a porcentagem dos que são recebidos; os roteadores, por exemplo, fazem isso. Explique 

a dificuldade de se fazer isso por uma conexão TCP. 

Suponha que o TCP opere em um enlace de 1 Gbps. 

a. Supondo que o TCP possa utilizar a largura de banda completa continuamente, quanto tempo 
seria necessário para que os números de sequência se reiniciem ciclicamente por completo? 

b. Suponha que um campo adicional de carimbo de tempo de 32 bits seja incrementado 1.000 
vezes durante o tempo de reinício cíclico que você encontrou no item (a). Quanto tempo 
levaria para o carimbo de tempo ser reiniciado? 

Suponha que o TCP opere por um enlace STS-768 de 40 Gbps. 

a. Supondo que o TCP possa utilizar a largura de banda completa continuamente, quanto 
tempo seria necessário para que os números de sequência se reiniciem ciclicamente 
por completo? 

b. Suponha que um campo adicional de carimbo de tempo de 32 bits seja incrementado 
1.000 vezes durante o tempo de reinício cíclico que você encontrou no item (a). Quanto 
tempo levaria para o carimbo de tempo ser reiniciado? 
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Se o host A recebe dois pacotes SYN da mesma porta do host remoto B, o segundo pode ser ou 
uma retransmissão do original ou, se B tiver falhado e sido reinicializado, uma solicitação de 
conexão inteiramente nova. 

a. Descreva a diferença entre esses dois casos conforme visto pelo host A. 

b. Forneça uma descrição algorítmica daquilo que a camada TCP precisa fazer ao receber um 
pacote SYN. Considere os casos de pacote duplicado/novo do item (a), além da possibilidade 
de que ninguém esteja escutando na porta de destino. 

Suponha que x e y sejam dois números de sequência do TCP Escreva uma função para determinar 

se x vem antes de y (na notação da Request for Comments 793, “x =< y”) ou depois de y; sua 

solução deverá funcionar mesmo quando os números de sequência são reiniciados ciclicamente. 

Suponha que exista uma conexão TCP ociosa entre os sockets A e B. Um terceiro esteve 

bisbilhotando a rede e descobriu o número de sequência atual nas duas pontas. 

a. Suponha que o bisbilhoteiro envie para A um pacote forjado, aparentemente proveniente de 
B, e com 100 bytes de dados novos. O que acontece? (Dica: Procure na Request for Comments 
793 sobre o que o TCP faz quando recebe um ACK que não é um “ACK aceitável”.) 

b. Suponha que o bisbilhoteiro envie para cada ponta um pacote de dados de 100 bytes forjado, 
mas aparentemente proveniente da outra ponta. O que acontece agora? O que aconteceria se 
A mais tarde enviasse 200 bytes de dados para B? 

Suponha que a entidade A se conecte à Internet por meio de uma rede sem fios usando DHCP 

para atribuir endereços IP. A abre várias conexões Telnet (usando TCP) e depois é desconectado 

da rede sem fios. A entidade B então se conecta e recebe o mesmo endereço IP que A havia 
recebido. Supondo que B fosse capaz de adivinhar a que host(s) A estava conectado, descreva 
uma sequência de mensagens de sondagem que poderiam permitir que B obtenha informações 

de estado suficientes para dar continuidade às conexões de 4. 

Normalmente existem programas de diagnóstico que registram os 100 primeiros bytes, digamos, 

de cada conexão TCP para determinado par de (host, porta). Esboce o que precisa ser feito com cada 

pacote TCP recebido, P para determinar se eles contêm dados que pertencem aos 100 primeiros 
bytes de uma conexão com o host HOST na porta PORTA. Considere que o cabeçalho IP é PIPCAB, 

o cabeçalho TCP é PTCPCAB e os campos de cabeçalho são os mesmos indicados nas Figuras 3.16 

e 5.4. (Dica: Para obter os números de sequência iniciais (ISNs), você terá que examinar cada pacote 

com o bit SYN marcado. Ignore o fato de que os números de sequência por fim serão reutilizados.) 

Se um pacote chega ao host A com o endereço de origem B, ele poderia facilmente ter sido 

forjado por qualquer terceiro host C. No entanto, se A aceita uma conexão TCP de B, então, 

durante o three-way handshake A enviou ISN; ao endereço de B e recebeu uma confirmação 
dele. Se C não estiver localizado de modo que possa bisbilhotar a rede e descobrir o valor de 

ISN;, então pode parecer que C não seria capaz de forjar a resposta para B. 

Porém, o algoritmo para escolher ISN; dá a outros hosts não relacionados uma chance justa de 

adivinhá-lo. Especificamente, A escolhe ISN, com base em um valor de relógio no momento da 

conexão. A Request for Comments 793 especifica que esse valor de relógio será incrementado a 

cada 4 us; a implementação Berkeley comum simplificou isso para incrementar por 250.000 (ou 

256.000) uma vez por segundo. 

a. Dada essa implementação simplificada de incrementar uma vez por segundo, explique como 
um host qualquer C poderia se passar por B pelo menos na abertura de uma conexão TCP. 
Você pode considerar que B não responde a pacotes SYN +ACK que A envie a B enquanto está 
sendo enganado por C. 

b. Supondo que os RT'Ts reais podem ser estimados para algo em torno de 40 ms, quantas 
tentativas você esperaria que seriam necessárias para implementar a estratégia da parte 
(a) com a implementação TCP não simplificada de “um incremento a cada 4 us”? 

O algoritmo de Nagle, embutido na maioria das implementações do TCP exige que o emissor 

mantenha um segmento parcial de dados (mesmo que com PUSH) até que um segmento inteiro 

seja acumulado ou que chegue o ACK pendente mais recente. 

a. Suponha que as letras abcdefghi sejam enviadas, uma vez por segundo, por uma conexão TCP 
com um RTT de 4,1 segundos. Desenhe uma linha de tempo indicando quando cada pacote é 
enviado e o que ele contém. 
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b. Se essas letras fossem digitadas por uma conexão Telnet full-duplex, o que o usuário veria? 

c. Suponha que as mudanças de posição do mouse sejam enviadas pela conexão. Supondo 
que várias mudanças de posição sejam enviadas a cada RTT, como um usuário perceberia o 
movimento do mouse com e sem o algoritmo de Nagle? 

Suponha que um cliente C se conecte repetidamente via TCP a determinada porta no servidor S, 

e que todas as vezes é C quem inicia o fechamento. 

a. Quantas conexões TCP por segundo C pode fazer aqui antes de colocar todas as portas 
disponíveis no estado TIME WAIT? Suponha que as portas efêmeras do cliente estejam no 
intervalo de 1024-5119, e que TIME WAIT dure 60 segundos. 

b. A implementação TCP derivada de Berkeley normalmente permite que um socket no estado 
TIME WATT seja reaberto antes que TIME WAIT expire, se o número de sequência mais 
alto usado pela antiga instância da conexão for menor que o ISN usado pela nova instância. 
Isso resolve o problema dos dados antigos serem aceitos como novos; porém, TIME WAIT 
também serve ao propósito de tratar FINs finais atrasados. O que essa implementação teria 
de fazer para resolver isso e ainda conseguir compatibilidade estrita com o requisito do 
TCP de que um FIN enviado a qualquer instante antes ou durante o TIME WATT de uma 
conexão receba a mesma resposta? 

Explique por que o TIME WAIT é um problema mais sério se o servidor iniciar o fechamento do 

que se o cliente o fizer. Descreva uma situação razoável em que isso poderia acontecer. 

Qual é a justificativa para o aumento exponencial no valor do tempo limite de expiração 

proposto por Karn e Partridge? Por que, especificamente, um aumento linear (ou mais lento) 

poderia ser menos desejável? 

O algoritmo de Jacobson/Karels define o valor do TempoExpiração em 4 desvios médios acima 

da média. Considere que os tempos de ida e volta do pacote individual seguem uma distribuição 

estatística normal, para a qual desvios de média 4 são 7 desvios-padrão. Usando tabelas 
estatísticas, por exemplo, qual é a probabilidade de que um pacote leve mais de um tempo de 

TempoExpiração para chegar? 

Suponha que uma conexão TCP com tamanho de janela 1, perca um pacote a cada dois. Aqueles 

que conseguem chegar possuem RTT=1 segundo. O que acontece? O que acontece com 

TempoExpiração? Faça isso para dois casos: 

a. Depois que um pacote por fim é recebido, continuamos de onde paramos, retomando 
com RTTEstimado inicializado com seu valor anterior à expiração do tempo limite e com 
TempoExpiração valendo o dobro disso. 

b. Depois que um pacote por fim é recebido, retomamos com TempoExpiração inicializado como o 
último valor usado para o intervalo de do tempo limite de expiração após um recuo exponencial. 

Nos quatro exercícios a seguir, os cálculos envolvidos são simples se feitos com uma planilha. 

Suponha, no mecanismo de retransmissão adaptativa do TCP que RTT Estimado é 4,0 segundos 

em algum ponto e os RTTs medidos depois disso são todos 1,0 segundo. Quanto tempo é 

necessário antes que o valor de TempoExpiração, calculado pelo algoritmo de Jacobson/ 

Karels, fique abaixo de 4,0 segundos? Suponha um valor inicial plausível de Desvio; qual é a 

sensibilidade da sua resposta a essa escolha? Use 6=1/8. 

Suponha, no mecanismo de retransmissão adaptativa do TCP que RTTEstimado seja 90 em 

algum ponto e que os RTTs medidos mais tarde sejam todos 200. Quanto tempo levará antes que 

o valor de TempoExpiração, calculado pelo algoritmo de Jacobson/Karels, fique abaixo de 300? 

Suponha um valor de Desvio inicial de 25; use ô= 1/8. 

Suponha que o RTT medido do TCP seja 1,0 segundo, exceto que cada N-ésimo RTT seja 

4,0 segundos. Qual é o maior N, aproximadamente, que não resulta em expirações do tempo 

limite após estabilização (ou seja, para o qual o TempoExpiração de Jacobson/Karels permanece 

maior que 4.0 segundos)? Use ô=1/8. 

Suponha que o TCP esteja medindo RTTs de 1,0 segundo, com um desvio médio de 0,1 

segundo. De repente, o RTT salta para 5,0 segundos, sem desvio. Compare os comportamentos 

dos algoritmos original e de Jacobson/Karels para calcular o valor de TempoExpiração. 

Especificamente, quantas expirações de tempo limite são encontrados com cada algoritmo? Qual 

é o maior TempoExpiração calculado? Use 6=1/8. 
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Suponha que, quando um segmento TOP é enviado mais de uma vez, consideramos 

RTTAmostra como sendo o tempo entre a transmissão original e o ACK, como na 

Figura 5.10(a). Mostre que, se uma conexão com uma janela de 1 pacote perde um a 

cada dois pacotes (ou seja, cada pacote é transmitido duas vezes), então RTTEstimado 

aumenta para infinito. Considere TempoExpiração = RTTEstimado; os dois algoritmos 

apresentados no texto sempre definem TempoExpiração como sendo ainda maior. (Dica: 

RTTEstimado = RTTEstimado + x (RTTAmostra — RTTEstimado). 

Suponha que, quando um segmento TCP é enviado mais de uma vez, consideramos RTTAmostra 

como sendo o tempo entre a transmissão mais recente e o ACK, como na Figura 5.10(b). 

Considere, por precisão, que TempoExpiração =2 x RTTEstimado. Esboce um cenário em que 

nenhum pacote é perdido, mas RTTEstimado converge para um terço do RTT verdadeiro, e 

forneça um diagrama ilustrando o estado final após estabilização. (Dica: Comece com um salto 

repentino no RTT verdadeiro para um valor pouco acima do TempoExpiração estabelecido.) 

Consulte o Request for Comments 793 para descobrir como o TCP deve responder se um FIN ou 

um RST chegar com um número de sequência diferente do PróximoByteEsperado. Considere 

quanto o número de sequência está dentro da janela de recepção e quando não está. 

Uma das finalidades de TIME WAIT é tratar do caso em que um pacote de dados de uma 

primeira instância de uma conexão chega muito tarde e é aceito como um pacote da segunda 

instância. 

a. Explique por que, para que isso aconteça (na ausência de TIME WATT), os hosts envolvidos 
teriam de trocar vários pacotes em sequência depois que o pacote atrasado fosse enviado, 
mas antes que ele fosse entregue. 

b. Proponha um cenário de rede que poderia levar em consideração tal entrega atrasada. 

Proponha uma extensão ao TCP pela qual uma extremidade de uma conexão possa repassar sua 

conexão a um terceiro host; ou seja, se A estivesse conectado a B, e A repassasse sua conexão a C, 

então depois disso C estaria conectado a B, e não a A. Especifique os novos estados e transições 

necessárias no diagrama de transição de estados do TCP e quaisquer novos tipos de pacote 
envolvidos. Você pode considerar que todas as partes entenderão essa nova opção. Em que 
estado A deve entrar imediatamente depois desse repasse? 

O recurso de abertura simultânea do TCP raramente é utilizado. 

a. Proponha uma mudança no TCP em que isso não seja permitido. Indique que mudanças 
seriam feitas no diagrama de estados (e, se necessário, nas respostas de eventos não 
mostrados no diagrama). 

b. Seria razoável que o TCP deixasse de permitir o fechamento simultâneo? 

c. Proponha uma mudança no TCP de modo que SYNs simultâneos trocados por dois hosts 
levem a duas conexões separadas. Indique que mudanças no diagrama de estados isso 
acarreta, e também que mudanças no cabeçalho seriam necessárias. Observe que isso agora 
significa que mais de uma conexão pode existir para determinado par de (host, porta)s. 

(Você também poderia analisar o primeiro item de “Discussão” na página 87 do Request for 
Comments 1122.) 

O TCP é um protocolo bastante simétrico, mas o modelo cliente/servidor não o é. Considere um 

protocolo assimétrico semelhante TCP em que somente o lado do servidor recebe um número 

de porta visível pelas camadas da aplicação. Os sockets no lado do cliente simplesmente seriam 
abstrações que podem ser conectadas a portas do servidor. 

a. Proponha os dados do cabeçalho e a semântica da conexão de uma solução que seja capaz de 
dar suporte a isso. O que você usará para substituir o número de porta do cliente? 

b. Que forma TIME WAIT toma agora? Como isso seria visto através da interface de 
programação? Suponha que um socket cliente agora pudesse ser reconectado um número 
arbitrariamente grande de vezes a determinada porta do servidor, se os recursos assim 
permitirem. 

c. Analise o protocolo rsh/rlogin. Como a situação descrita nos itens anteriores impediria o seu 
funcionamento? 
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O exercício seguinte trata do estado FIN_WAIT_2 do TOP (ver Figura 5.7). 

a. Descreva como um cliente poderia deixar um servidor corretamente configurado no estado 
FIN WAIT 2 indefinidamente. Que recurso do protocolo do servidor é necessário aqui para 
criar este cenário? 

b. Experimente fazer isso com algum servidor apropriado existente. Escreva um cliente stub ou 
use um cliente Telnet existente, capaz de conectar-se a uma porta qualquer. Use o utilitário 
netstat para verificar que o servidor está no estado FIN WAIT 2. 

O Request for Comments 1122 afirma (sobre o TCP): 

Um host PODE implementar uma sequência de fechamento TCP do tipo “half-duplex”, de modo 

que uma aplicação que tenha invocado o CLOSE não pode continuar a ler dados da conexão. Se tal 

host enviar uma chamada de CLOSE enquanto dados recebidos ainda estão pendentes no TCP ou 
se novos dados forem recebidos depois que o CLOSE for invocado, seu TCP DEVE enviar um RST 
para mostrar que os dados foram perdidos. 

Esboce um cenário envolvendo essa situação, em que os dados enviados pelo host que está 

fechando a conexão (não para ele!) são perdidos. Você pode considerar que o host remoto, ao 

receber um RST, descarta todos os dados recebidos ainda não lidos nos buffers. 

Quando o TCP envia um (SYN, NúmeroSeg =x) ou (FIN, NúmeroSeq =x}, o ACK correspondente 

possui Confirmação =x + 1; ou seja, SYNs e FINs ocupam uma unidade no espaço do número 

de sequência. Isso é necessário? Se for, dê um exemplo de uma ambiguidade que surgiria se a 

Confirmação correspondente fosse x em vez de x+ 1; se não, explique por quê. 

Analise o formato genérico para as opções do cabeçalho TCP conforme descrito no Request for 

Comments 793. 

a. Esboce uma estratégia que expandiria o espaço disponível para as opções além do limite atual 
de 44 bytes. 

b. Sugira uma extensão para o TCP permitindo que o emissor de uma opção seja capaz de 
especificar o que o receptor deve fazer se a opção não for entendida. Liste várias ações do 
receptor que poderiam ser úteis e tente dar uma aplicação de exemplo de cada uma destas ações. 

O cabeçalho TCP não tem um campo de ID de inicialização. Por que não existe um problema em 

que uma extremidade de uma conexão TCP falha e é reinicializada, depois envia uma mensagem 

com um ID que ela usou anteriormente? 

Suponha que tenhamos que implementar a operação de montagem de um sistema de 

arquivos remoto usando um protocolo RCP não confiável, que fornece a semântica “zero ou 

mais”. Se uma resposta a uma mensagem for recebida, isso é melhorado para uma semântica 

“pelo menos uma vez”. Definimos a função read(n) de modo que ela retorne o enésimo bloco 

especificado, em vez do próximo bloco na sequência; desse modo, ler uma vez é o mesmo que 

ler duas vezes, e a semântica “pelo menos uma vez”, assim, é o mesmo que “exatamente uma 
vez”. 

a. Para quais outras operações do sistema de arquivos não existe diferença entre as semânticas 
“pelo menos uma vez” e “exatamente uma vez”? Considere open, create, write, seek, opendir, 
readdir, mkdir, delete (também conhecido como unlink) e rmdir. 

b. Para as operações restantes, quais podem ter sua semântica alterada para conseguir 
equivalência entre “pelo menos uma vez” e “exatamente uma vez”? Que operações do sistema 
de arquivos são irreconciliáveis com a semântica “pelo menos uma vez”? 

c. Suponha que a semântica da chamada de sistema rmdir seja agora tal que o diretório 
indicado é removido se existir, e nada seja feito caso contrário. Como você escreveria um 
programa para excluir diretórios capaz de distinguir entre esses dois casos? 

O sistema de arquivos remotos NFS baseado no RPC é algumas vezes considerado como tendo 

um desempenho de write inferior ao esperado. No NES, uma resposta RPC de um servidor à 

solicitação write de um cliente significa que os dados são fisicamente gravados no disco do 

servidor, e não apenas colocados em uma fila. 

a. Explique o gargalo que poderíamos esperar, mesmo com largura de banda infinita, se o 
cliente enviar todas as suas solicitações de write por meio de um único canal lógico, e 
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explique por que o uso de um conjunto de canais poderia ajudar. Dica: você precisará 
conhecer um pouco sobre controladores de disco. 

b. Suponha que a resposta do servidor significa apenas que os dados foram colocados na fila 
para o disco. Explique como isso poderia levar a uma perda de dados que não ocorreria com 
um disco local. Observe que uma falha do sistema imediatamente após os dados serem 
enfileirados não conta, pois isso também causaria perda de dados em um disco local. 

c. Uma alternativa seria que o servidor respondesse imediatamente à confirmação da 
solicitação write e enviasse sua própria solicitação separada mais tarde, para confirmar a 
escrita física. Proponha diferentes semânticas de RPC para conseguir o mesmo efeito, mas 
com uma única solicitação/resposta lógica. 

Considere um cliente e servidor usando um mecanismo de RPC que inclua uma abstração de 

canal e IDs de inicialização. 

a. Descreva um cenário envolvendo a reinicialização do servidor, de modo que uma solicitação 
RPC seja enviada duas vezes pelo cliente e seja executada duas vezes pelo servidor, com 
apenas um único ACK. 

b. Como o cliente poderia perceber que isso aconteceu? O cliente conseguiria ter certeza de que 
isso aconteceu? 

Suponha que uma solicitação RPC tenha o formato “Incremente o valor do campo X do bloco 

de disco N em 10%”. Especifique um mecanismo a ser usado pelo servidor em execução para 

garantir que uma solicitação que chega seja executada exatamente uma vez, mesmo que o 

servidor falhe enquanto estiver no meio da operação. Considere que as escritas em bloco 

individuais no disco ou são completadas ou então o bloco não é alterado. Você também pode 
considerar que alguns blocos designados para “registro de desfazer” estão disponíveis. Seu 
mecanismo deverá incluir como o servidor RPC deve se comportar na reinicialização. 

Considere um cliente SunRPC enviando uma solicitação a um servidor. 

a. Sob quais circunstâncias o cliente pode ter certeza de que sua solicitação foi executada 
exatamente uma vez? 

b. Suponha que quiséssemos acrescentar a semântica “no máximo uma vez” ao SunRPC. Que 
mudanças teriam de ser feitas? Explique por que a inclusão de um ou mais campos nos 
cabeçalhos existentes não seria suficiente. 

Suponha que o TCP tivesse que ser usado como a camada de transporte subjacente em um 

protocolo RPC; cada conexão TCP deve transportar um fluxo sequencial de solicitações e 

respostas. Quais são os campos TCP equivalentes, se houver, aos seguintes campos RPC: 

ID do canal 

ID da mensagem 

ID de inicialização 

Um tipo de mensagem para solicitações 

Um tipo de mensagem para respostas 

Um tipo de mensagem para confimagoes 

g. Um tipo de mensagem para mensagens “você está vivo?” 

Quais destes o protocolo RPC operando em cima do TCP teria que oferecer? Existiria algum 

equivalente das confirmações implícitas? 

Escreva um programa de teste que use a interface de sockets para enviar mensagens entre um 

par de estações de trabalho Unix conectadas por alguma tecnologia de LAN (por exemplo, 

Ethernet, ou 802.11). Use esse programa de teste para realizar as experiências a seguir. 

a. Meça a latência de ida e volta do TCP e do UDP para diferentes tamanhos de mensagem (por 
exemplo, 1 byte, 100 bytes, 200 bytes, ..., 1.000 bytes). 

b. Meça a vazão do TCP e do UDP para mensagens de 1 KB, 2 KB, 3 KB, ..., 32 KB. Represente 
graficamente a vazão medida como uma função do tamanho da mensagem. 

c. Meça a vazão do TCP enviando 1 MB de dados de um host para outro. Faça isso em um laço 
que envie uma mensagem de um certo tamanho, por exemplo, 1.024 iterações de um laço 
que envia mensagens de 1 KB. Repita a experiência com diferentes tamanhos de mensagem e 
represente os resultados graficamente. 
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Tente encontrar situações nas quais uma aplicação RTP poderia realizar razoavelmente o 

seguinte: 

e Enviar vários pacotes basicamente ao mesmo tempo, os quais precisam de diferentes 
carimbos de tempo. 

e Enviar pacotes em diferentes momentos, os quais precisam do mesmo carimbo de tempo. 

Argumente, por conseguinte, que os carimbos de tempo do RTP precisam, pelo menos em alguns 

casos, ser fornecidos (ao menos indiretamente) pela aplicação. (Dica: Pense em casos onde a 

taxa de transmissão e a taxa de reprodução podem ser distintas.) 

Fazer com que o relógio do carimbo de tempo RTP conte o tempo em unidades de um tempo 

de quadro ou um tempo da amostra de voz seria a resolução mínima para garantir a reprodução 

precisa, mas a unidade de tempo normalmente é muito menor; qual é o propósito disso? 

Suponha que queiramos que a quantidade total dos relatórios RTCP retornados pelos receptores 

não correspondam a mais do que 5% do fluxo RTP primário de saída. Se cada relatório tiver 

84 bytes, o tráfego RTP for de 320 kbps, e houver 1000 destinatários, com que frequência os 

receptores individuais podem enviar os relatórios? E se houver 10.000 destinatários? 

O REC 3550 especifica que o intervalo de tempo entre os relatórios RTCP do receptor inclui 

um fator de randomização para evitar que todos os receptores transmitam ao mesmo tempo. 

Se todos os receptores enviassem relatórios no mesmo subintervalo de 5% do seu intervalo 

de tempo de resposta, o tráfego RTCP enviado pelos receptores competiria com o tráfego RTP 

enviado pelos emissores. 

a. Os receptores de vídeo poderiam razoavelmente esperar e enviar seus relatórios até que a 
tarefa de prioridade mais alta de processar e exibir um quadro fosse concluída; isso poderia 
significar que suas transmissões RTCP estão sincronizadas nos limites de quadro. É provável 
que esta seja uma preocupação séria? 

b. Com 10 receptores, qual é a probabilidade de todos eles enviarem relatórios em um 
subintervalo em particular de 5%? 

c. Com 10 receptores, qual é a probabilidade de metade deles enviar em um subintervalo em 
particular de 5%? Multiplique isso por 20 para uma estimativa da probabilidade de que 
metade envie no mesmo subintervalo qualquer de 5%. (Dica: De quantas maneiras podemos 
escolher 5 receptores dentre os 102) 

O que um servidor poderia realmente fazer com os dados da taxa de perda de pacotes e os dados 

de jitter obtidos nos relatórios de receptor? 

Proponha um mecanismo para decidir quando relatar um pacote RTP como perdido. Como o seu 

mecanismo se compara com os mecanismos de retransmissão adaptativa do TCP da Seção 5.2.6? 


Controle de congestionamento 
e alocação de recursos 


A mesma mão que o fez justo também o fez bom. 
William Shakespeare 


E E Problema: alocar recursos E 


Até o momento, já vimos camadas suficientes da hierarquia de protocolos de rede para entender 
como os dados podem ser transferidos entre os processos de redes heterogêneas. Agora, vamos 
passar para um problema que se aplica a toda a pilha de protocolos — como alocar recursos 

de forma eficaz e justa entre um conjunto de usuários concorrentes. Os recursos, sendo 
compartilhados, incluem a largura de banda dos enlaces e os buffers nos roteadores ou switches 
onde os pacotes são enfileirados, aguardando a transmissão. Os pacotes disputam em um roteador 
pelo uso de um enlace, com cada pacote participando da disputa sendo colocado em uma fila, 
aguardando sua vez para ser transmitido pelo enlace. Quando muitos pacotes estão disputando 
pelo mesmo enlace, a fila transborda e os pacotes precisam ser descartados. Quando isso 

se torna um evento comum, a rede é considerada congestionada. A maioria das redes oferece um 
mecanismo de controle de congestionamento para lidar com tal situação. 

O controle de congestionamento e a alocação de recursos são “dois lados da mesma moeda”. 

Por um lado, se a rede assume um papel ativo na alocação de recursos — por exemplo, escalonando 
qual circuito virtual usa determinado enlace físico durante certo período de tempo -, então 

o congestionamento pode ser evitado, tornando assim o controle de congestionamento 
desnecessário. Porém, a tarefa de alocar recursos na rede é difícil de ser feita com precisão, pois 

os recursos em questão são distribuídos por toda a rede; vários enlaces conectando uma série de 
roteadores precisam ser escalonados. Por outro lado, você sempre pode permitir que as origens 
de pacotes enviem tantos dados quantos quiserem, e depois recuperar-se do congestionamento, 
se ele ocorrer. Essa é a técnica mais fácil, mas pode ser danosa porque muitos pacotes podem 

ser descartados pela rede antes que o congestionamento possa ser controlado. Além disso, 

é exatamente nas ocasiões em que a rede fica congestionada — ou seja, quando os recursos 

se tornam escassos em comparação à demanda - que a necessidade de alocação de recursos entre 
os usuários concorrentes é mais fortemente percebida. Há também soluções intermediárias, 

onde são tomadas decisões de alocação exatas, mas o congestionamento ainda pode ocorrer 

e, logo, algum mecanismo ainda é necessário para recuperar-se dele. Se você chama essa 

solução combinada de controle de congestionamento ou alocação de recursos, isso não importa 
realmente. Em alguns casos, são ambos. 

O controle de congestionamento e a alocação de recursos envolvem hosts e elementos da rede, 
como os roteadores. Nos elementos da rede, diversas estratégias de enfileiramento podem 

ser usadas para controlar a ordem em que os pacotes são transmitidos e quais pacotes são 
descartados. A estratégia de enfileiramento também pode segregar tráfego, ou seja, evitar 

que os pacotes de um usuário afetem indevidamente os pacotes de outro usuário. Nos hosts finais, 
o mecanismo de controle de congestionamento controla a velocidade com que as origens podem 
enviar pacotes. Isso é feito em um esforço para evitar que o congestionamento ocorra em primeiro 
lugar e, se ocorrer, para ajudar a eliminar o congestionamento. 
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Este capítulo começa com uma visão geral do controle de congestionamento e da alocação 

de recursos. Depois, discutiremos diferentes disciplinas de enfileiramento que podem ser 
implementadas nos roteadores dentro da rede, seguido por uma descrição do algoritmo de 
controle de congestionamento fornecido pelo TCP nos hosts. A quarta seção explora diversas 
técnicas envolvendo tanto roteadores como hosts, que visam evitar o congestionamento antes 
que ele se torne um problema. Finalmente, examinaremos a grande área da qualidade de serviço. 
Consideramos as necessidades das aplicações de receber diferentes níveis de alocação de recursos 
na rede, e descrevemos diversas maneiras pelas quais elas podem solicitar esses recursos e a rede 
pode atender as solicitações. 


6.1 Problemas na alocação de recursos 


A alocação de recursos e o controle de congestionamento são questões complexas e têm sido o assunto 
de muito estudo desde que a primeira rede foi projetada. Essas ainda são áreas ativas de pesquisa. Um 
fator que torna essas questões complexas é que elas não são isoladas a um único nível de hierarquia 
de protocolo. A alocação de recursos é implementada parcialmente nos roteadores ou switches den- 
tro da rede e parcialmente no protocolo de transporte sendo executado nos hosts finais. Os sistemas 
finais utilizam protocolos de sinalização para informar seus requisitos de recursos aos nós da rede, 
que respondem com informações sobre a disponibilidade de recursos. Um dos principais objetivos 
deste capítulo é definir uma estrutura na qual esses mecanismos podem ser entendidos, além de dar 
os detalhes relevantes sobre uma amostra representativa dos mecanismos. 

Devemos esclarecer nossa terminologia antes de nos aprofundarmos ainda mais. Por alocação de recur- 
sos queremos dizer o processo pelo qual os elementos da rede tentam atender as demandas concorrentes 
que as aplicações têm pelos recursos da rede — principalmente largura de banda do enlace e espaço de 
buffer nos roteadores ou switches. Naturalmente, nem sempre será possível atender a todas as demandas, 
significando que alguns usuários ou aplicações podem receber menos recursos da rede do que eles 
desejam. Parte do problema de alocação de recursos é decidir quando dizer não e a quem dizer não. 

Usamos o termo controle de congestionamento para descrever os esforços feitos pelos nós da rede 
para impedir ou responder a condições de sobrecarga. Como o congestionamento geralmente é ruim 
para todos, o primeiro objetivo é diminuir o congestionamento, ou impedi-lo em primeiro lugar. Isso 
pode ser obtido simplesmente persuadindo alguns hosts a pararem de enviar dados, melhorando 
assim a situação para todos os outros hosts. Porém, é mais comum que os mecanismos de controle de 
congestionamento tenham alguma noção de justiça — ou seja, eles tentam compartilhar a dor entre todos 
os usuários, em vez de causar muita dor em alguns poucos. Assim, vemos que muitos mecanismos de 
controle de congestionamento terão uma noção de alocação de recursos embutida. 

Também é importante entender a diferença entre controle de fluxo e controle de congestionamento. 
Controle de fluxo, como vimos na Seção 2.5, significa evitar que um emissor rápido sobrecarregue um 
receptor lento. Controle de congestionamento, por outro lado, serve para evitar que um conjunto de 
emissores enviem muitos dados para a rede devido à falta de recursos em algum ponto. Esses dois concei- 
tos normalmente são confundidos; como veremos, eles também compartilham alguns mecanismos. 


6.1.1 Modelo de rede 


Começamos definindo três recursos que se destacam na arquitetura da rede. Em sua maior parte, esse é 
um resumo do material apresentado nos capítulos anteriores, que é relevante ao problema de alocação 
de recursos. 


Rede de comutação de pacotes 

Consideramos a alocação de recursos em uma rede de comutação de pacotes (ou inter-rede) consistindo 
em vários enlaces e switches (ou roteadores). Como a maior parte dos mecanismos descritos neste 
capítulo foi projetada para uso na Internet, e, portanto, definida originalmente em termos de roteadores 
em vez de switches, usamos o termo roteador durante toda a nossa discussão. O problema é basicamente 
o mesmo, seja em uma rede ou em uma inter-rede. 
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Origem 1 FIGURA 6.1 Um roteador que é um gargalo em potencial. 
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Nesse tipo de ambiente, determinada origem pode ter capacidade mais do que suficiente no enlace 
de saída imediato para enviar um pacote, porém, em algum local no meio de uma rede, seus pacotes 
encontram um enlace que está sendo usado por muitas origens de tráfego diferentes. A Figura 6.1 
ilustra essa situação — dois enlaces de alta velocidade estão alimentando dados em um enlace de baixa 
velocidade. Isso é diferente do que ocorre nas redes de acesso compartilhado, como Ethernet e token 
rings, onde a origem pode observar diretamente o tráfego na rede e decidir se enviará um pacote ou 
não de acordo com esse tráfego. Já vimos os algoritmos usados para alocar largura de banda nas redes 
de acesso compartilhado (Capítulo 2). Esses algoritmos de controle de acesso são, em certo sentido, 
semelhantes aos algoritmos de controle de congestionamento em uma rede comutada. 


Perceba que o controle de congestionamento é um problema diferente do roteamento. Embora seja verdade 
que um enlace congestionado poderia receber um peso de aresta elevado pelo protocolo de roteamento 

e, como consequência, os roteadores o contornariam, “contornar” um enlace congestionado não resolve 

o problema de congestionamento. Para ver isso, não precisamos examinar mais do que a rede simples 
representada na Figura 6.1, em que todo o tráfego precisa fluir pelo mesmo roteador para alcançar o destino. 
Embora esse seja um exemplo extremo, é comum que haja algum roteador que não possa ser contornado.* 


Esse roteador pode se tornar congestionado, e não haverá nada que o mecanismo de roteamento possa fazer 
a respeito disso. Esse roteador congestionado, às vezes, é chamado de gargalo. 





*Também é importante notar que a complexidade do roteamento na Internet é tal que a simples obtenção de uma rota 
razoavelmente direta e sem ciclos é praticamente o melhor que você pode esperar. Contornar o congestionamento seria 
considerado como a “cereja do bolo”. 





Fluxos sem conexão 

Para grande parte de nossa discussão, consideramos que a rede é essencialmente sem conexão, com 
qualquer serviço orientado a conexão sendo implementado no protocolo de transporte que está em 
execução nos hosts finais. (Explicaremos a designação “essencialmente” um pouco mais adiante.) 
Esse é precisamente o modelo da Internet, onde o IP oferece um serviço de entrega de datagramas 
sem conexões e o TCP implementa uma abstração de conexão fim a fim. Observe que essa suposição 
exclui as redes de circuitos virtuais, como ATM e X.25(ver Seção 3.1.2). Nessas redes, uma mensagem 
de configuração de conexão atravessa a rede quando um circuito é estabelecido. Essa mensagem de 
configuração reserva um conjunto de buffers para a conexão em cada roteador, oferecendo assim 
uma forma de controle de congestionamento — uma conexão só é estabelecida se buffers suficientes 
puderem ser alocados a ela em cada roteador. A maior limitação dessa técnica é que ela ocasiona uma 
subutilização de recursos — os buffers reservados para determinado circuito não ficam disponíveis 
para uso por outro tráfego, mesmo que não estejam sendo usados atualmente por esse circuito. O foco 
deste capítulo está nas técnicas de alocação de recursos que se aplicam a uma inter-rede, e por isso 
focalizamos principalmente as redes sem conexões. 
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FIGURA 6.2 Diversos fluxos passando por um conjunto de 
roteadores. 
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Precisamos qualificar a expressão sem conexão, pois nossa classificação de redes como sendo sem 
conexão ou orientada a conexão é um tanto restritiva; existe uma área nebulosa entre elas. Particu- 
larmente, a implicação de uma rede sem conexão, em que todos os datagramas são completamente 
independentes, é muito forte. Os datagramas certamente são comutados de forma independente, 
mas normalmente um fluxo de datagramas entre determinado par de hosts flui por um determinado 
conjunto de roteadores. Essa ideia de um fluxo - uma sequência de pacotes enviados entre um par 
origem/destino e seguindo a mesma rota através da rede — é uma abstração importante no contexto da 
alocação de recursos; é essa ideia que usaremos neste capítulo. 

Uma das vantagens da abstração do fluxo é que os fluxos podem ser definidos em diferentes níveis 
de detalhe. Por exemplo, um fluxo pode ser host a host (ou seja, ter os mesmos endereços de host de 
origem/destino) ou processo a processo (ou seja, ter os mesmos pares de host/porta de origem/desti- 
no). Nesse último caso, um fluxo é essencialmente o mesmo que um canal, da forma que usamos esse 
termo no decorrer deste livro. O motivo para introduzirmos um termo novo é que um fluxo é visível aos 
roteadores dentro da rede, enquanto um canal é uma abstração fim a fim. A Figura 6.2 ilustra diversos 
fluxos passando por uma série de roteadores. 

Como vários pacotes relacionados fluem por cada roteador, às vezes faz sentido manter alguma in- 
formação de estado para cada fluxo, informações que podem ser usadas para tomar decisões de alocação 
de recursos sobre os pacotes que pertencem ao fluxo. Esse estado costuma ser chamado de estado soft; a 
principal diferença entre o estado soft e o estado hard é que o estado softnem sempre precisa ser criado 
e removido explicitamente pela sinalização. O estado soft representa um meio-termo entre uma rede 
puramente sem conexão, que não mantém o estado nos roteadores, e uma rede puramente orientada a 
conexão, que mantém o estado hard nos roteadores. Em geral, a operação correta da rede não depende 
do estado soft estar presente (cada pacote ainda é roteado corretamente, independentemente desse 
estado), mas quando um pacote pertence a um fluxo para o qual o roteador está atualmente mantendo 
o estado soft, então o roteador tem melhores condições de tratar o pacote. 

Observe que um fluxo pode ser definido implicitamente ou estabelecido explicitamente. No primeiro 
caso, cada roteador observa pacotes que estejam trafegando entre o mesmo par origem/destino — o 
roteador faz isso inspecionando os endereços no cabeçalho -— e trata esses pacotes como pertencentes 
ao mesmo fluxo, para fins de controle de congestionamento. No segundo caso, a origem envia uma 
mensagem de configuração de fluxo pela rede, declarando que um fluxo de pacotes está para ser ini- 
ciado. Embora os fluxos explícitos comprovadamente não sejam diferentes de uma conexão por uma 
rede orientada a conexão, chamamos a atenção para esse caso porque, mesmo quando estabelecido 
explicitamente, um fluxo não implica qualquer semântica fim a fim e, em particular, não implica a 
entrega confiável e ordenada de um circuito virtual. Ele simplesmente existe para fins de alocação de 
recursos. Veremos exemplos de fluxos implícitos e explícitos neste capítulo. 


Modelo de serviço 
Na parte inicial deste capítulo, vamos nos concentrar nos mecanismos que assumem o modelo de serviço 
de melhor esforço da Internet. Com o serviço de melhor esforço, cada pacote é tratado exatamente da 
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mesma maneira, com as extremidades não tendo oportunidade para pedir à rede que um de seus fluxos 
receba certas garantias ou atendimento preferencial. A definição de um modelo de serviço que admita 
algum tipo de garantia — por exemplo, garantindo a largura de banda necessária para um fluxo de vídeo — 
é o assunto da Seção 6.5. Diz-se que tal modelo de serviço oferece qualidade de serviço (QoS — Quality of 
Service) diversas. Como veremos, há realmente um espectro de possibilidades, variando desde um modelo 
de serviço de melhor esforço até um em que os fluxos individuais recebem garantias quantitativas de 
QoS. Um dos maiores desafios é definir um modelo de serviço que atenda as necessidades de uma grande 
variedade de aplicações e até mesmo leve em conta as aplicações que serão inventadas no futuro. 


6.1.2 Classificação 


Existem inúmeras maneiras em que os mecanismos de alocação de recursos diferem, tornando uma 
classificação completa uma proposta difícil. Por enquanto, descrevemos três dimensões ao longo das 
quais os mecanismos de alocação de recursos podem ser caracterizados; distinções mais sutis serão 
mostradas no decorrer deste capítulo. 


Centrado no roteador versus centrado no host 

Os mecanismos de alocação de recursos podem ser classificados em dois grupos gerais: aqueles que 
enfrentam o problema de dentro da rede (ou seja, nos roteadores ou switches) e aqueles que o enfrentam 
nas bordas da rede (ou seja, nos hosts, talvez dentro do protocolo de transporte). Como acontece que os 
roteadores dentro da rede e os hosts nas bordas da rede participam da alocação de recursos, a questão 
real é onde se encontra a maior responsabilidade. 

Em um projeto centrado no roteador, cada roteador tem responsabilidade por decidir quando os 
pacotes são encaminhados e selecionar quais pacotes são descartados, além de informar aos hosts, que 
estão gerando o tráfego na rede, quantos pacotes eles podem enviar. Em um projeto centrado no host, 
os hosts finais observam as condições da rede (por exemplo, quantos pacotes eles estão obtendo com 
sucesso por intermédio da rede) e ajustam seu comportamento de acordo. Observe que esses dois 
grupos não são mutuamente exclusivos. Por exemplo, uma rede que coloca o maior peso por controlar 
o congestionamento nos roteadores ainda espera que os hosts finais respeitem quaisquer mensagens 
de aviso que os roteadores enviem, enquanto os roteadores nas redes que usam o controle de conges- 
tionamento fim a fim ainda possuem alguma política, por mais simples que seja, para decidir quais 
pacotes descartar quando as filas estiverem cheias. 


Baseado em reserva versus baseado em feedback 

Uma segunda maneira como os mecanismos de alocação de recursos às vezes são classificados é de 
acordo com seu uso de reserva ou feedback. Em um sistema baseado em reserva, alguma entidade (por 
exemplo, o host final) pede à rede certa quantidade de capacidade no momento em que um fluxo é 
estabelecido. Cada roteador, então, aloca recursos suficientes (buffers e/ou porcentagem de largura de 
banda do enlace) para satisfazer a essa solicitação. Se a solicitação não puder ser satisfeita em algum 
roteador, pois isso comprometeria seus recursos, então o roteador rejeita a reserva. Isso é semelhante a 
quando recebemos um sinal de ocupado ao tentar fazer uma ligação telefônica. Em uma técnica baseada 
em feedback, os hosts finais começam a enviar dados sem primeiro reservar qualquer capacidade, 
e depois ajustam sua taxa de envio de acordo com o feedback que recebem. Esse feedback pode ser 
explícito (ou seja, um roteador congestionado envia para o host uma mensagem “mais devagar, por 
favor”) ou implícito (ou seja, o host final ajusta sua taxa de envio de acordo com o comportamento da 
rede observável externamente, como as perdas de pacotes). 

Observe que um sistema baseado em reserva sempre implica um mecanismo de alocação de reserva 
centrado no roteador. Isso porque cada roteador é responsável por acompanhar o quanto de sua 
capacidade está atualmente reservado e por decidir se novas reservas podem ser aceitas. Roteadores 
também podem ter que certificar-se que cada host se mantenha nos limites da reserva que ele fez. Se 
um host enviar dados mais rapidamente do que ele afirmou que faria quando fez a reserva, então os 
pacotes desse host são bons candidatos para descarte, caso o roteador fique congestionado. Por outro 
lado, um sistema baseado em feedback pode implicar um mecanismo centrado no roteador ou no host. 
Normalmente, se o feedback for explícito, então o roteador estará envolvido, pelo menos até certo ponto, 
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no esquema de alocação de recursos. Se o feedback for implícito, então quase todo o peso cairá sobre 
o host final; os roteadores silenciosamente descartam pacotes quando ficam congestionados. 

As reservas não precisam ser feitas pelos hosts finais. É possível que um administrador de rede reserve 
recursos a fluxos ou a agregações de tráfego maiores, conforme veremos na Seção 6.5.3. 


Baseado em janela versus baseado em taxa 

Uma terceira forma de classificar os mecanismos de alocação de recursos é de acordo com se eles são 
baseados em janela ou baseados em taxa. Essa é uma das áreas, observadas anteriormente, onde meca- 
nismos e terminologia semelhantes são usados para controle de fluxo e controle de congestionamento. O 
mecanismo de controle de fluxo e o de alocação de recursos precisam ambos de uma forma de expressar, 
para o emissor, quantos dados ele pode transmitir. Existem duas maneiras gerais de fazer isso: com uma 
janela ou com uma taxa. Já vimos os protocolos de transporte baseados em janela, como o TCP em 
que o receptor anuncia uma janela ao emissor. Essa janela corresponde a quanto espaço em buffer o 
receptor tem, e limita quantos dados o emissor pode enviar; ou seja, ele dá suporte a controle de fluxo. 
Um mecanismo semelhante — anúncio de janela — pode ser usado dentro da rede para reservar espaço de 
buffer (ou seja, para admitir a alocação de recursos). Os mecanismos de controle de congestionamento 
do TCP descritos na Seção 6.3, são baseados em janela. 

Também é possível controlar o comportamento de um emissor usando uma taxa, ou seja, quantos 
bits por segundo o receptor ou a rede são capazes de absorver. O controle baseado em taxa faz sentido 
para muitas aplicações de multimídia, que tendem a gerar dados em alguma taxa média e que precisam, 
pelo menos, de alguma vazão mínima para ser útil. Por exemplo, um codec de vídeo do tipo descrito na 
Seção 7.2.3 poderia gerar vídeo a uma taxa média de 1 Mbps com uma taxa de pico de 2 Mbps. Como 
veremos mais adiante neste capítulo, a caracterização de fluxos baseada em taxa é uma escolha lógica 
em um sistema baseado em reserva, que admite diferentes qualidades de serviço — o emissor faz uma 
reserva para tantos bits por segundo, e cada roteador ao longo do caminho determina se pode admitir 
essa taxa, dados os outros fluxos com os quais ele se comprometeu. 


Resumo da classificação da alocação de recursos 

A classificação das técnicas de alocação de recursos em dois pontos diferentes ao longo de cada uma das 
três dimensões, como fizemos aqui, parece sugerir até oito estratégias exclusivas. Embora oito técnicas 
diferentes certamente sejam possíveis, observamos que, na prática, duas estratégias gerais parecem ser 
mais predominantes; essas duas estratégias estão ligadas ao modelo de serviço básico da rede. 

Por um lado, um modelo de serviço de melhor esforço normalmente implica que o feedback está 
sendo usado, pois tal modelo não permite que os usuários reservem a capacidade da rede. Isso, por 
sua vez, significa que a maior parte da responsabilidade pelo controle de congestionamento recai 
sobre os hosts finais, talvez com alguma assistência dos roteadores. Na prática, tais redes utilizam 
informações baseadas em janela. Essa é a estratégia geral adotada na Internet e o foco das Seções 
6.3 e 6.4. 

Por outro lado, um modelo de serviço baseado em QoS provavelmente implica alguma forma de 
reserva.! Espera-se que o suporte para essas reservasprecise de um envolvimento significativo do 
roteador, por exemplo, para enfileirar pacotes de maneiras diferentes, dependendo do nível de recursos 
reservados que eles exigem. Além disso, é natural expressar tais reservas em termos de taxa, pois as 
janelas só estão indiretamente relacionadas a quanta largura de banda da rede um usuário precisa. 
Discutiremos esse assunto na Seção 6.5. 


6.1.3 Critérios de avaliação 


O problema final é saber se um mecanismo de alocação de recursos é bom ou não. Lembre-se que, na 
declaração do problema no início deste capítulo, colocamos a questão de como uma rede aloca seus 
recursos de forma eficaz e justa. Isso sugere, pelo menos, duas medições gerais pelas quais um esquema 
de alocação de recursos pode ser avaliado. Vamos considerar uma de cada vez. 


1Como veremos na Seção 6.5, as reservas de recursos poderiam ser feitas por gerentes de rede, em vez de hosts. 
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Alocação de recursos eficaz 
Um bom ponto de partida para a avaliação da eficácia de um esquema de alocação de recursos é con- 
siderar as duas medições principais das redes: vazão e atraso. Naturalmente, queremos o máximo de 
vazão e o mínimo de atraso possível. Infelizmente, embora na superfície possa parecer que o aumento da 
vazão também signifique redução do atraso, isso não acontece. Um modo garantido para um algoritmo 
de alocação de recursos aumentar o vazão é permitir o máximo de pacotes possível na rede, de modo a 
elevar a utilização de todos os enlaces até 100%. Faríamos isso para evitar a possibilidade de um enlace 
tornar-se ocioso, porque um enlace ocioso necessariamente prejudicaa vazão. O problema com essa 
estratégia é que aumentar o número de pacotes na rede também aumenta o tamanho das filas em cada 
roteador. Filas maiores, por sua vez, significam pacotes que são atrasados por mais tempo na rede. 
Para descrever esse relacionamento, alguns projetistas de rede propuseram o uso da razão entre a 
vazão e o atraso como uma medida para avaliar a eficácia de um esquema de alocação de recursos. Essa 
razão, às vezes, é chamada de potência da rede:? 


Potência = Vazão/Atraso 


Observe que não é óbvio que a potência sejaa medida certa para julgar a eficácia da alocação de 
recursos. Por um lado, a teoria por trás da potência é baseada em uma rede de enfileiramento M/M/1 
que considera filas infinitas; as redes reais possuem buffers finitos e, às vezes, precisam descartar pacotes. 
Por outro, a potência normalmente é definida em relação a uma única conexão (fluxo); não está claro 
como ela pode ser estendida para várias conexões competindo entre si. Apesar dessas limitações um 
tanto severas, nenhuma alternativa teve grande aceitação, e por isso a potência continua a ser usada. 

O objetivo é maximizar essa razão, que é uma função de quanta carga você coloca sobre a rede. A 
carga, por sua vez, é definida pelo mecanismo de alocação de recursos. A Figura 6.3 contém uma curva 
de potência representativa na qual, idealmente, o mecanismo de alocação de recursos opera no pico 
dessa curva. À esquerda do pico, o mecanismo está sendo muito conservador; ou seja, ele não está per- 
mitindo que pacotes suficientes sejam enviados para manter os enlaces ocupados. À direita do pico, 
tantos pacotes estão sendo permitidos na rede que os aumentos no atraso em virtude do enfileiramento 
estão começando a dominar quaisquer pequenos ganhos no vazão. 

É interessante notar que essa curva de potência se parece muito com a curva de vazão do sistema, 
em um sistemacomputacional multiprogramado. A vazão do sistema melhora à medida que mais tarefas 
são admitidas no sistema, até que ele atinge um ponto em que existem tantas tarefas executando que o 
sistema começa a emperrar (gasta todo o seu tempo trocando páginas da memória) e a vazão começa 
a cair. 

Como veremos em outras seções deste capítulo, muitos esquemas de controle de congestionamento 
são capazes de controlar a carga de maneiras muito primitivas. Ou seja, não é possível simplesmente 


Vazão/atraso 








LL Ml íÊxz 
Carga Carga 


ideal FIGURA 6.3 Razão entre vazão e atraso como função da carga. 


2A definição na realidade é Potência=Vazão*/Atraso, onde 0 <a< 1; «= 1 resulta na potência sendo maximizada no joelho 
da curva do atraso. A vazão é medida em unidades de dados (por exemplo, bits) por segundo, e o atraso, em segundos. 

Como este não é um livro sobre teoria de enfileiramento, oferecemos apenas uma breve descrição de uma fila M/M/1. O 1 
significa que ela tem um único servidor, e os Ms significam que a distribuição dos tempos de chegada e atendimento do pacote 
é “Markoviana”, ou seja, exponencial. 
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“girar um botão” ligeiramente e permitir que apenas um pequeno número de pacotes adicionais entre 
na rede. Como consequência, os projetistas de rede precisam se preocupar com o que acontece quando 
o sistema está operando sob carga extremamente pesada - ou seja, no canto mais à direita da curva da 
Figura 6.3. De modo ideal, gostaríamos de evitar a situação em que a vazão do sistema vai para zero 
porque o sistema está emperrando. Usando terminologia de rede, queremos um sistema que seja estável 
-no qual os pacotes continuam a passar pela rede mesmo quando a rede está operando sob carga intensa. 
Se um mecanismo não for estável, a rede pode experimentar um colapso por congestionamento. 


Alocação de recursos de forma justa 

A utilização eficaz dos recursos da rede não é o único critério para julgar um esquema de alocação 
de recursos. Também precisamos considerar a questão da justiça. Porém, rapidamente entramos em 
águas agitadas quando tentamos definir o que constitui exatamente a alocação de recursos justa. Por 
exemplo, um esquema de alocação de recursos baseado em reserva oferece um modo explícito de criar 
parcialidade controlada. Com esse esquema, poderíamos usar reservas para permitir que um fluxo de 
vídeo receba 1 Mbps através de algum enlace, enquanto uma transferência de arquivos recebe apenas 
10 Kbps pelo mesmo enlace. 

Na ausência de informações explícitas dizendo o contrário, quando vários fluxos compartilham um 
enlace específico, gostaríamos que cada fluxo recebesse uma fatia igual da largura de banda. Essa defi- 
nição pressupõe que uma fatia justa da largura de banda significa uma fatia igual de largura de banda. 
Mas, até mesmo na ausência de reservas, fatias iguais podem não ser o mesmo que fatias imparciais. 
Será que também deveríamos considerar o tamanho dos caminhos sendo comparados? Por exemplo, 
conforme ilustramos na Figura 6.4, o que pode ser considerado justo quando um fluxo de quatro saltos 
está competindo com três fluxos de um salto? 

Supondo que justo significa igual e que todos os caminhos têm o mesmo tamanho, o pesquisador 
de redes Raj Jain propôs uma métrica que pode ser usada para quantificar a justiça de um mecanismo 
de controle de congestionamento. O índice de justiça de Jain é definido da seguinte maneira. Dado 
um conjunto de vazões de fluxo (x1, X2, ...X,) (medidas em unidades coerentes, como bits/segundo), a 
seguinte função atribui um índice de justiça aos fluxos: 

Ea) 


FOX ox A E 


i=l “i 


O índice de justiça sempre resulta em um número entre 0 e 1, com 1 representando a maior justiça. 
Para entender a intuição por trás dessa métrica, considere o caso em que todos os n fluxos recebem um 
vazão de 1 unidade de dados por segundo. Podemos ver que o índice de justiça nesse caso é 


=1 





nxn 


Agora suponha que um fluxo receba uma vazão de 1 + A. Agora, o índice de justiça é 


(n-D++A) _ n?+2n4+4º 
n(n-1+(1+4)}) nº+2nA4+nA? 








Observe que o denominador excede o numerador em (n-1)A2. Assim, não importa se o fluxo excedente 
estava recebendo mais ou menos recursos do que todos os outros fluxos (A positivo ou negativo), o ín- 
dice de justiça agora caiu para um valor inferior a um. Outro caso simples a considerar é onde apenas 
k dos n fluxos recebem vazão igual, e os n-k usuários restantes recebem vazão zero, quando o índice 


de justiça cai para k/n. 


FIGURA 6.4 Um fluxo de quatro saltos competindo com três fluxos de um salto. 
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6.2 Disciplinas de enfileiramento A. 


Filas 


Independentemente da simplicidade ou da sofisticação do mecanismo de alocação de recursos, cada 
roteador precisa implementar alguma estratégia de enfileiramento que controla o modo como os pacotes 
são colocados em buffer enquanto esperam para serem transmitidos. O algoritmo de enfileiramento pode 
ser considerado como alocando tanto largura de banda (quais pacotes são transmitidos) quanto espaço 
de buffer (quais pacotes são descartados). Isso também afeta diretamente a latência experimentada por 
um pacote, determinada por quanto tempo um pacote espera para ser transmitido. Esta seção introduz 
dois algoritmos de enfileiramento comuns — primeiro a entrar, primeiro a sair (FIFO — First In, First Out) 
e enfileiramento justo (FQ — Fair Queuing) - ntifica diversas variações que foram propostas. 


6.2.1 FIFO 


A ideia do enfileiramento FIFO, também chamado primeiro a chegar, primeiro a ser atendido (FCFS 
— First Come First Served), é simples: o primeiro pacote que chega a um roteador é o primeiro pacote a 
ser transmitido. Isso é ilustrado na Figura 6.5(a), que mostra uma fila FIFO com posições (“slots”) para 
conter até oito pacotes. Visto que a quantidade de espaço no buffer em cada roteador é finita, se um 
pacote chegar e a fila (espaço do buffer) estiver cheia, então o roteador descarta esse pacote, como 
mostra a Figura 6.5(b). Isso é feito sem considerar a qual fluxo o pacote pertence ou a importância 
do pacote. Isso, às vezes, é chamado descarte da cauda, pois os pacotes que chegam no final da FIFO 
são descartados. 

Observe que o descarte da cauda e a FIFO são duas ideias que podem ser separadas. A FIFO é uma 
estratégia de escalonamento — determina a ordem em que os pacotes são transmitidos. O descarte da 
cauda é uma política de descarte — ela determina quais pacotes são descartados. Como filas FIFO e 
descarte da cauda são as ocorrências mais simples de estratégia de escalonamento e de política de 
descarte, respectivamente, eles, geralmente, são vistos como um único conjunto — a implementação 
de enfileiramento mais simples. Infelizmente, esse conjunto normalmente é conhecido apenas como 
enfileiramento FIFO, quando deveria ser chamado mais precisamente de FIFO com descarte da cauda. 
A Seção 6.4 contém um exemplo de outra política de descarte, que usa um algoritmo mais complexo 
do que “existe uma posição livro no buffer?” para decidir quando descartar pacotes. Essa política de 
descarte pode ser usada com FIFO ou com estratégias de escalonamento mais complexas. 

FIFO com descarte da cauda, como o mais simples de todos os algoritmos de enfileiramento, era 
o mais usado nos roteadores da Internet no momento em que este livro foi escrito. Essa técnica de 


(a) 


Pacote Próxima posição Próximo M 
chegando livre no buffer a transmitir 
—— + m 





Posições livres Pacotes enfileirados 


no buffer 
) Pacote Próximo 
chegando a transmitir 
— r 
% FIGURA 6.5 (a) Enfileiramento FIFO; (b) descarte da cauda 


Descarte em uma fila FIFO. 
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enfileiramento simples empurra toda a responsabilidade pelo controle de congestionamento e alocação 
de recursos para as bordas da rede. Assim, a forma predominante de controle de congestionamento na 
Internet atualmente não pressupõe a ajuda dos roteadores: o TCP tem a responsabilidade por detectar 
e responder ao congestionamento. Veremos como isso funciona na Seção 6.3. 

Uma variação simples do enfileiramento FIFO básico é o enfileiramento por prioridade. A ideia é 
marcar cada pacote com uma prioridade; a marca poderia ser transportada, por exemplo, no cabeçalho 
IP conforme veremos na Seção 6.5.3. Os roteadores, então, implementam várias filas FIFO, uma para 
cada classe de prioridade. O roteador sempre transmite os pacotes da fila de maior prioridade, se essa 
fila não estiver vazia, antes de prosseguir para a fila de próxima prioridade. Dentro de cada prioridade, 
os pacotes ainda são gerenciados de um modo FIFO. Essa ideia é uma pequena fuga do modelo de 
entrega pelo melhor esforço, mas não chega ao ponto de fazer garantia alguma a qualquer classe de 
prioridade em particular. Ela simplesmente permite que os pacotes de alta prioridade “furem a fila”, 
indo para o começo da mesma. 

O problema com o enfileiramento por prioridade, naturalmente, é que a fila de alta prioridade pode 
tomar o lugar de todas as outras filas. Ou seja, se houver pelo menos um pacote de alta prioridade na fila 
de alta prioridade, as filas de prioridade menor não serão atendidas. Para que isso seja viável, é preciso 
haver limites rígidos sobre quanto tráfego de alta prioridade é inserido na fila. Deve ficar bem claro que 
não podemos permitir que os usuários definam seus próprios pacotes com alta prioridade de um modo 
descontrolado; temos que impedir completamente que eles façam isso ou oferecer alguma forma de frear 
os usuários. Um modo óbvio de fazer isso é usar a economia — a rede poderia cobrar mais para oferecer 
pacotes de alta prioridade do que pacotes de baixa prioridade. Contudo, existem desafios significativos 
para a implementação desse esquema em um ambiente descentralizado, como a Internet. 

Uma situação em que o enfileiramento por prioridade é usado na Internet é para proteger os pacotes 
mais importantes, normalmente, as atualizações de roteamento que são necessárias para estabilizar as 
tabelas de roteamento após uma mudança de topologia. Frequentemente, há uma fila especial para tais 
pacotes, que podem ser identificados pelo Ponto de Código de Serviços Diferenciados(anteriormente, o 
campo TOS) no cabeçalho IP Na verdade, esse é um caso simples da ideia de “Serviços diferenciados”, o 
assunto da Seção 6.5.3. 


6.2.2 Enfileiramento justo 


O problema principal com o enfileiramento FIFO é que ele não faz distinção entre diferentes origens de 
tráfego ou, na linguagem introduzida na seção anterior, ele não separa pacotes de acordo com o fluxo 
ao qual eles pertencem. Esse é um problema em dois níveis diferentes. Em um nível, não está claro se 
qualquer algoritmo de controle de congestionamento implementado inteiramente na origem pode ser 
capaz de controlar o congestionamento com tão pouca ajuda dos roteadores. Vamos adiar o julgamento 
deste ponto até a próxima seção, quando discutiremos sobre o controle de congestionamento no TCP 
Em outro nível, como o mecanismo de controle de congestionamento inteiro é implementado nas 
origens e o enfileiramento FIFO não oferece um meio de policiar o quanto as origens estão respeitando 
esse mecanismo, é possível que uma origem (fluxo) mal comportada(o) capture uma fração arbitra- 
riamente grande da capacidade da rede. Considerando a Internet novamente, certamente é possível 
que determinada aplicação não use TCP e, como consequência, evite seu mecanismo de controle de 
congestionamento fim a fim. (As aplicações como a telefonia por Internet fazem isso atualmente.) Esse 
tipo de aplicação é capaz de inundar os roteadores da Internet com seus próprios pacotes, fazendo com 
que os pacotes de outras aplicações sejam descartados. 

O enfileiramento justo (FQ) é um algoritmo que foi proposto para resolver esse problema. A ideia do 
FQ é manter uma fila separada para cada fluxo atualmente sendo tratado pelo roteador. O roteador, então, 
serve a essas filas em um padrão de rodízio, conforme ilustrado na Figura 6.6. Quando um fluxo envia 
pacotes muito rapidamente, então sua fila se enche. Quando uma fila atinge determinado tamanho, os 


“Esta é uma estratégia bastante comum em redes modernas, e é uma consequência direta do aumento do poder 
computacional dos hosts finais, que há muito deixaram de ser “terminais burros”. Este movimento permitiu a simplificação 
(e, assim, também o barateamento) de equipamentos no núcleo da rede. (N.T.) 
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pacotes adicionais pertencentes à fila desse fluxo são descartados. Desse modo, determinada origem não 
pode aumentar arbitrariamente sua fatia de uso da capacidade da rede à custa de outros fluxos. 

Observe que o FQ não envolve o roteadordizendo algo às origens de tráfego a respeito do estado do 
roteador ou limitando de alguma maneira a velocidade com que determinada origem envia pacotes. Em 
outras palavras, o FQ ainda é projetado para ser usado em conjunto com um mecanismo de controle 
de congestionamento fim a fim. Ele simplesmente separa o tráfego para que origens de tráfego mal 
comportadas não interfiram com aquelas que estão fielmente implementando o algoritmo fim a fim. 
O FQ também impõe a justiça entre uma coleção de fluxos gerenciados por um algoritmo de controle 
de congestionamento bem comportado. 

Por mais simples que seja a ideia básica, ainda existem alguns detalhes que você precisa acertar. 
A complicação principal é que os pacotes sendo processados em um roteador não têm necessariamente 
o mesmo tamanho. Para alocar verdadeiramente a largura de banda do enlace de saída de uma maneira 
justa, é preciso levar em consideração o tamanho do pacote. Por exemplo, se um roteador estiver geren- 
ciando dois fluxos, um com pacotes de 1.000 bytes e o outro com pacotes de 500 bytes (talvez devido 
à fragmentação causada por um roteador anterior), então um simples serviço de rodízio dos pacotes 
provenientes das filas de cada fluxo dará ao primeiro fluxo dois terços da largura de banda do enlace e 
ao segundo fluxo apenas um terço de sua largura de banda. 

O que realmente queremos é um rodízio bit a bit; ou seja, o roteador transmite um bit do fluxo 1, 
depois um bit do fluxo 2, e assim por diante. Logicamente, não é viável intercalar os bits de pacotes 
diferentes. O mecanismo FQ, portanto, simula esse comportamento determinando quando certo pacote 
terminaria de ser transmitido se estivesse sendo enviado usando um rodízio bit a bit, e depois usando 
esse tempo de término para determinar a sequência em que os pacotes serão transmitidos. 

Para entender esse algoritmo usado para aproximar o rodízio bit a bit, considere o comportamento 
de um único fluxo e imagine um relógio cujo ponteiro se move sempre que um bit é transmitido por 
todos os fluxos ativos. (Um fluxo está ativo quando possui dados na fila.) Para esse fluxo, seja P; o tama- 
nho do pacote i, seja S;a hora em que o roteador começa a transferir o pacote i, e seja F; a hora em que 
o roteador termina de transmitir o pacote i. Se P; é expresso em termos de quantas vezes o ponteiro do 
relógio precisa se mover para transmitir o pacote i (tendo em mente que o tempo avança de 1 unidade 
toda vez que esse fluxo recebe 1 bit de serviço), então é fácil ver que F;= Si+ P,. 

Quando começamos a transmitir o pacote i? A resposta a essa pergunta depende se o pacote i chegou 
antes ou depois que o roteador terminou de transmitir o pacote i— 1proveniente desse fluxo. Se foi antes, 
então logicamente o primeiro bit do pacote i é transmitido imediatamente depois do último bit do pacote 
i- 1. Por outro lado, é possível que o roteador termine de transmitir o pacote i- 1 muito antes que i 
chegue, significando que houve um período de tempo durante o qual a fila para esse fluxo esteve vazia, 
de modo que o mecanismo de rodízio não pode transmitir pacote algum proveniente desse fluxo. Se A; 
indica a hora em que o pacote i chega ao roteador, então S;= max(F,.,,4;). Assim, podemos calcular 


E =max(E,, A)+P 


Agora, prosseguimos para a situação em que existe mais de um fluxo, e descobrimos que há uma 
dificuldade para determinar A;. Não podemos simplesmente ler a hora no relógio de parede quando o 
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pacote chega. Como já observamos, queremos que a hora avance de uma unidade toda vez que todos 
os fluxos ativos receberem um bit de serviço no regime de rodízio bit a bit, de modo que precisamos de 
um relógio que avance mais lentamente quando houver mais fluxos. Especificamente, o relógio precisa 
avançar de uma unidade quando n bits forem transmitidos se houver n fluxos ativos. Esse relógio será 
usado para calcular A;. 

Agora, para cada fluxo, calculamos F; para cada pacote que chega, usando a fórmula anterior. Depois, 
tratamos todos osF; como carimbos de tempo, e o próximo pacote a ser transmitido é sempre o pacote 
que possui o menor carimbo de tempo — aquele que, com base no raciocínio anterior, deverá terminar 
a transmissão antes de todos os outros. 

Observe que isso significa que um pacote pode chegar em um fluxo e, por ser mais curto que um 
pacote de algum outro fluxo que já está na fila, esperando para ser transmitido, pode ser inserido na 
fila na frente desse pacote maior. Porém, isso não significa que um pacote recém-chegado pode tomar 
o lugar de um pacote que atualmente esteja sendo transmitido. É essa falta de capacidade de se apro- 
priar de um lugar na fila que evita que a implementação do FQ que descrevemos simule exatamente o 
esquema de rodízio bit a bit que estamos tentando aproximar. 

Para ver melhor como funciona essa implementação do enfileiramento justo, considere o exemplo 
dado na Figura 6.7. A parte (a) mostra as filas para dois fluxos; o algoritmo seleciona os dois pacotes do 
fluxo 1 para serem transmitidos antes do pacote na fila do fluxo 2, devido aos seus tempos de término 
ocorrerem mais cedo. Em (b), o roteador já começou a enviar um pacote do fluxo 2 quando o pacote 
do fluxo 1 chega. Embora o envio do pacote chegando ao fluxo 1 teria terminado antes do fluxo 2 se 
estivéssemos usando o enfileiramento justo bit a bit perfeito, a implementação não se apropria do lugar 
do pacote do fluxo 2. 

Existem duas coisas a observar sobre o enfileiramento justo. Primeiro, o enlace nunca fica ocioso, 
contanto que haja pelo menos um pacote na fila. Qualquer esquema de enfileiramento com essa 
característica é considerado capaz de conservar o trabalho. Um efeito de conservar o trabalho é que se 
eu estiver compartilhando um enlace com muitos fluxos que não estão enviando dado algum, eu posso 
usar a capacidade completa do enlace para o meu fluxo. Porém, assim que os outros fluxos começarem 
a enviar dados, eles começarão a usar sua fatia e a capacidade disponível para o meu fluxo cairá. 

A segunda coisa a observar é que, se o enlace estiver totalmente carregado e houver n fluxos enviando 
dados, eu não posso usar mais do que 1/n da largura de banda do enlace. Se eu tentar enviar mais do que 
isso, meus pacotes receberão carimbos de tempo cada vez maiores, fazendo com que fiquem na fila por 
mais tempo, aguardando a transmissão. Por fim, a fila ficará cheia - embora o fato de os meus pacotes ou 
os de mais alguém serem descartados seja uma decisão que não é determinada em virtude de estarmos 
usando o enfileiramento justo. Isto é determinado pela política de descarte; o FQ é um algoritmo de 
escalonamento que, como a fila FIFO, pode ser combinado com diversas políticas de descarte. 

Como o FQ conserva o trabalho, qualquer largura de banda que não for usada por um fluxo estará 
automaticamente disponível para outros fluxos. Por exemplo, se tivermos quatro fluxos passando por 
um roteador, e todos eles estiverem enviando pacotes, então cada um receberá um quarto da largura de 
banda. Mas se um deles estiver ocioso por tempo suficiente para que todos os seus pacotes saiam pela fila 
do roteador, então a largura de banda disponível será compartilhada entre os três fluxos restantes, que 
receberão um terço da largura de banda cada um. Assim, podemos pensar no FQ como algo oferecendo 


Fluxo 1 Fluxo 2 
Fluxo 1 Fluxo 2 Saída (chegando) (transmitindo) Saída 


He E cla 


FIGURA 6.7 Exemplo do enfileiramento justo em ação: (a) pacotes mais curtos são enviados primeiro; (b) o envio do pacote maior, já 
em andamento, é completado primeiro. 
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uma fatia mínima garantida da largura de banda para cada fluxo, com a possibilidade de obter mais do 
que sua garantia se outros fluxos não estiverem usando suas fatias. 

É possível implementar uma variação do FQ, chamada enfileiramento justo ponderado (WFO — Weighted 
Fair Queuing), que permite a atribuição de um peso a cada fluxo (fila). Esse peso especifica logicamente 
quantos bits serão transmitidos toda vez que o roteador atender a essa fila, o que efetivamente controla 
a porcentagem da largura de banda do enlace que o fluxo obterá. O FQ simples dá a cada fila um peso 
1, o que significa que, logicamente, apenas 1 bit é transmitido por vez de cada fila. Isso resulta em cada 
fluxo obtendo 1/n da largura de banda, onde existem n fluxos. Porém, com o WFQ, uma fila poderia ter 
um peso 2, uma segunda fila poderia ter um peso 1, e uma terceira fila poderia ter um peso 3. Supondo 
que cada fila sempre contenha um pacote esperando para ser transmitido, o primeiro fluxo receberia 
um terço da largura de banda disponível, o segundo receberia um sexto da largura de banda disponível 
e o terceiro receberia metade da largura de banda disponível. 

Embora tenhamos descrito o WFQ em termos de fluxos, observe que ele poderia ser implementado 
sobre classes de tráfego, onde as classes são definidas de alguma outra maneira, que não sejam os fluxos 
simples, introduzidos no início deste capítulo. Por exemplo, poderíamos usar alguns bits no cabeçalho IP 
para identificar as classes, e alocar uma fila e um peso a cada classe. É exatamente isso o que é proposto 
como parte da arquitetura de Serviços Diferenciados (Differentiated Services), descrita na Seção 6.5.3. 

Observe que um roteador realizando WQF precisa descobrir, de algum lugar, que pesos atribuir a 
cada fila, seja pela configuração manual ou por algum tipo de sinalização das origens. Nesse último caso, 
estamos passando para um modelo baseado em reserva. Apenas atribuir um peso a uma fila oferece uma 
forma um tanto fraca de reserva, pois esses pesos estão relacionados apenas indiretamente à largura de 
banda que o fluxo recebe. (A largura de banda disponível a um fluxo também depende, por exemplo, de 
quantos outros fluxos estão compartilhando o enlace.) Na Seção 6.5.2, veremos como o WFQ pode ser 
usado como um componente de um mecanismo de alocação de recursos baseado em reserva. 


Finalmente, observe que essa discussão inteira sobre gerenciamento de fila ilustra um princípio importante 
no projeto de sistemas, conhecido como separação entre política e mecanismo. A ideia é exibir cada 
mecanismo como uma caixa preta, que oferece um serviço com múltiplas funcionalidades, que podem ser 
controladas por um conjunto de botões. Uma política especifica uma configuração em particular desses 


botões, mas não sabe (ou não se importa com) como a caixa preta é implementada. Nesse caso, o mecanismo 
em questão é a estratégia de enfileiramento, e a política é uma configuração específica de qual fluxo recebe 
qual nível de serviço (por exemplo, prioridade ou peso). Na Seção 6.5, discutiremos algumas políticas que 
podem ser usadas com o mecanismo WFQ. 





6.3 Controle de congestionamento do TCP 


Esta seção descreve o exemplo predominante de controle de congestionamento fim a fim em uso 
atualmente, implementado pelo TCP. A estratégia essencial do TCP é enviar pacotes para a rede sem 
uma reserva e depois reagir a eventos observáveis que ocorram. O TCP assume apenas o enfileiramento 
FIFO nos roteadores da rede, mas também funciona com o enfileiramento justo. 

O controle de congestionamento do TCP foi introduzido na Internet no final da década de 1980 por 
Van Jacobson, aproximadamente oito anos após a pilha de protocolos TCP/IP ter se tornado operacional. 
Imediatamente antes dessa época, a Internet estava sofrendo de um colapso de congestionamento — os 
hosts enviavam seus pacotes com a velocidade que a janela anunciada permitisse, o congestionamento 
ocorria em algum roteador (causando a perda de pacotes), e então o tempo limite era atingido e os hosts 
retransmitiam seus pacotes, resultando em ainda mais congestionamento. 

De um modo geral, a ideia do controle de congestionamento do TCP é que cada origem determine 
quanta capacidade está disponível na rede, de modo que saiba quantos pacotes podem transitar segu- 
ramente. Quando uma origem qualquer tem essa quantidade de pacotes em trânsito, ela usa a chegada 
de um ACK como sinal de que um de seus pacotes chegou ao destino, e que, portanto, é seguro inserir 
um novo pacote na rede sem aumentar o nível de congestionamento. Por usar ACKs para definir o 
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andamento da transmissão de pacotes, o TCP é considerado autorregulado. Naturalmente, determinar a 
capacidade disponível em primeiro lugar não é uma tarefa fácil. Para piorar as coisas ainda mais, como 
outras conexões são feitas e desfeitas, a largura de banda disponível muda com o tempo, significando 
que qualquer origem precisa ser capaz de ajustar o número de pacotes que ela tem em trânsito. Esta 
seção descreve os algoritmos usados pelo TCP para resolver estes e outros problemas. 

Observe que, embora descrevamos esses mecanismos um de cada vez, dando assim a impressão de 
que estamos falando de três mecanismos independentes, é somente quando eles são tomados como 
um todo que temos o controle de congestionamento do TCP Além disso, embora comecemos aqui com 
a variante do controle de congestionamento do TCP normalmente chamado de TCP padrão, veremos 
que existem realmente muitas variantes do controle de congestionamento TCP em uso atualmente, e os 
pesquisadores continuam a explorar novos métodos para resolver esse problema. Alguns desses novos 
métodos são discutidos a seguir. 


6.3.1 Aumento aditivo/diminuição multiplicativa 


O TCP mantém uma nova variável de estado para cada conexão, chamada JanelaCongestionamento, que 
é usada pela origem para limitar quantos dados podem estar em trânsito em determinado momento. A 
janela de congestionamento é o equivalente em controle de congestionamento à janela anunciada do 
controle de fluxo. O TCP é modificado de modo que o número máximo de bytes de dados não confirma- 
dos permitidos é, agora, o menor valor entre a janela de congestionamento e a janela anunciada. Assim, 
usando as variáveis definidas na Seção 5.2.4, a janela efetiva do TCP é revisada da seguinte maneira: 


JanelaMáxima= MIN(JanelaCongestionamento;JanelaAnunciada) 
JanelaEfetiva=JanelaMáxima-—(UltimoByteEnviado-UltimoByteConfirmado). 


Ou seja, JanelaMáxima substitui JanelaAnunciada no cálculo de JanelaEfetiva. Assim, uma origem 
TCP tem permissão para transmitir não mais rápido do que o componente mais lento - a rede ou o host 
de destino — pode acomodar. 

O problema, naturalmente, é como o TCP descobre um valor apropriado para JanelaCongestionamen- 
to. Ao contrário da JanelaAnunciada, que é enviada pelo lado receptor da conexão, não há alguém para 
enviar uma JanelaCongestionamento adequada ao lado emissor do TCP A resposta é que a origem TCP 
define o valor de JanelaCongestionamento com base no nível de congestionamento que ela percebe existir 
na rede. Isso envolve diminuir a janela de congestionamento quando o nível de congestionamento sobe 
e aumentar a janela de congestionamento quando o nível de congestionamento diminui. Como um todo, 
o mecanismo normalmente é chamado aumento aditivo/diminuição multiplicativa (AIMD — Additive 
Increase/Multiplicative Decrease); o motivo para esse nome tão grande será esclarecido mais adiante. 

A questão principal, portanto, é como a origem determina que a rede está congestionada, e que 
deve diminuir a janela de congestionamento? A resposta é baseada na observação de que o motivo 
principal para os pacotes não serem entregues, resultando na expiração do tempo limite, é que um 
pacote foi descartado devido ao congestionamento. É raro que um pacote seja descartado devido a um 
erro durante a transmissão. Portanto, o TCP interpreta eventos de expiração do tempo limite como um 
sinal de congestionamento e reduz a taxa em que está transmitindo. Especificamente, toda vez que 
ocorre umaexpiração do tempo limite, a origem altera a JanelaCongestionamento para a metade do 
seu valor anterior. Essa diminuição da JanelaCongestionamento pela metade para cada expiração 
do tempo limite corresponde à parte “diminuição multiplicativa” do AIMD. 

Embora a JanelaCongestionamento seja definida em termos de bytes, é mais fácil entender a 
diminuição multiplicativa se pensarmos em termos de pacotes inteiros. Por exemplo, suponha que 
a JanelaCongestionamento seja atualmente definida como 16 pacotes. Se uma perda for detectada, a 
JanelaCongestionamento passa para 8. (Normalmente, uma perda é detectada quando ocorre uma ex- 
piração do tempo limite, mas, como veremos mais adiante, o TCP possui outro mecanismo para detectar 
pacotes descartados.) Perdas adicionais fazem com que a JanelaCongestionamento seja reduzida para 
4, depois 2, e finalmente para 1 pacote. A JanelaCongestionamento não tem permissão para diminuir 
abaixo do tamanho de um único pacote ou, na terminologia do TCP abaixo do tamanho máximo do 
segmento (MSS — Maximum Segment Size). 
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Origem Destino FIGURA 6.8 Pacotes em trânsito durante o aumento aditivo, com um pacote sendo 
acrescentado a cada RTT. 


Uma estratégia de controle de congestionamento que só diminui o tamanho da janela obviamente 
é muito conservadora. Também precisamos ser capazes de aumentar a janela de congestionamento 
para tirar proveito da capacidade que venha a ficar disponível na rede. Essa é a parte “aumento aditivo” 
do AIMD, e funciona da seguinte maneira: toda vez que a origem envia com sucesso uma quantidade 
de pacotes correspondente a uma JanelaCongestionamento - ou seja, cada pacote enviado durante o 
último RTT foi confirmado com ACKs-, ela aumenta a JanelaCongestionamento pelo valor equivalente 
a um pacote. Esse aumento linear é ilustrado na Figura 6.8. Observe que, na prática, o TCP não espera 
por uma janela inteira de ACKs para aumentar o tamanho da janela de congestionamento de um pacote, 
mas incrementa JanelaCongestionamento um pouco a cada ACK que chega. Especificamente, a janela 
de congestionamento é aumentada da seguinte forma toda vez que um ACK chega: 


Incremento = MSS x (MSS/JanelaCongestionamento) 
JanelaCongestionamento + = Incremento 


Ou seja, em vez de incrementar JanelaCongestionamento por um MSS inteiro de bytes a cada RTT, 
nós o incrementamos por uma fração do MSS toda vez que um ACK é recebido. Supondo que cada ACK 
confirme o recebimento de MSS bytes, então essa fração é MSS/JanelaCongestionamento. 

Esse padrão contínuode aumentar e diminuir a janela de congestionamento se mantém durante 
todo o ciclo de vida da conexão. Na verdade, se você representar o valor atual da JanelaCongestiona- 
mento como uma função do tempo, verá um padrão de “dente de serra”, conforme ilustra a Figura 6.9. 
O conceito importante a entender sobre o AIMD é que a origem está disposta a reduzir sua janela de 
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FIGURA 6.9 Padrão de “dente de serra” TCP típico. 
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congestionamento em uma taxa muito mais rápida do que a aumenta. Isso contrasta com a uma estratégia 
de aumento aditivo/diminuição aditiva, em que a janela seria aumentada em um pacote quando um 
ACK chega, e diminuída em um pacote quando ocorre uma expiração do tempo limite. Foi demons- 
trado que o AIMD é uma condição necessária para um mecanismo de controle de congestionamento 
ser estável (veja a seção “Leitura adicional”, ao final do capítulo). Um motivo intuitivo para diminuir 
a janela agressivamente e aumentá-la aos poucos é que as consequências de se ter uma janela muito 
grande são muito piores do que se ela for muito pequena. Por exemplo, quando a janela é muito grande, 
os pacotes que são descartados serão retransmitidos, tornando o congestionamento ainda pior; assim, 
é importante sair desse estado rapidamente. 

Finalmente, como a expiração do tempo limite é uma indicação de congestionamento que dispara 
a diminuição multiplicativa, o TCP precisa do mecanismo de expiração do tempo limite mais preciso 
que for possível. Já explicamos o mecanismo de expiração do tempo limite do TCP na Seção 5.2.6, e 
por isso não iremos repeti-lo aqui. As duas principais coisas a lembrar sobre esse mecanismo são que 
(1) os valores do tempo limite são definidos como uma função do RTT médio e do desvio padrão nessa 
média, e (2) devido ao custo de medir cada transmissão com um relógio preciso, o TCP apenas amos- 
tra o tempo de ida e volta uma vez por RTT (e não uma vez por pacote), usando um relógio de baixa 
precisão (500 ms). 


QUANDO A PERDA NÃO SIGNIFICA CONGESTIONAMENTO: TCP SOBRE REDES SEM FIOS 


Há uma situação em que o controle de congestionamento TCP tem uma tendência a falhar de modo 
espetacular. Quando um enlace descarta pacotes em uma taxa relativamente alta devido a erros de bits — 
algo que é muito comum nos enlaces sem fios —, o TCP interpreta isso erroneamente como um sinal de 
congestionamento. Consequentemente, o emissor TCP reduz sua velocidade, o que normalmente não tem 
efeito sobre a taxa de erros de bits, de modo que a situação pode continuar até que a janela de transmissão 
se reduza a um único pacote. Nesse ponto, a vazão alcançada pelo TCP será deteriorada para um pacote 
por tempo de ida e volta, o que pode ser muito menor do que a taxa apropriada para uma rede que não está 
realmente experimentando congestionamento. 

Dada essa situação, você poderá questionar como é que o TCP consegue funcionar em redes sem fios. 
Felizmente, existem diversas maneiras de resolver o problema. Normalmente, algumas etapas são realizadas 
na camada de enlace para reduzir ou ocultar as perdas de pacotes devido a erros de bits. Por exemplo, redes 
802.11 aplicam a correção antecipada de erros (FEC — Forward Error Correction) aos pacotes transmitidos 
de modo que alguma quantidade de erros possa ser corrigida pelo receptor. Outra técnica é realizar a 
retransmissão na camada de enlace, de modo que até mesmo se um pacote for danificado ou descartado, 
ele por fim será enviado com sucesso, e a perda inicial nunca se torna visível pelo TCP Cada uma dessas 
técnicas tem seus problemas: a FEC desperdiça alguma largura de banda e, às vezes, ainda deixará de corrigir 
erros, enquanto a retransmissão aumenta tanto o RTT da conexão como sua variância, prejudicando o 
desempenho. 

Outra técnica usada em algumas situações é dividir a conexão TCP em segmentos sem fios e com fios. 
Existem muitas variações sobre essa ideia, mas a técnica básica é tratar as perdas no segmento com fios 
como sinais de congestionamento, mas tratar as perdas no segmento sem fios como sendo causada por erros 
de bits. Esse tipo de técnica tem sido usado em redes por satélite, em que o RTT já é tão grande que você 
realmente não deseja torná-lo maior. Porém, diferente das técnicas da camada de enlace, esta é uma mudança 
fundamental na operação fim a fim do protocolo; ela também significa que os caminhos direto e reverso da 
conexão precisam passar pela mesma “caixa intermediária” que está realizando a separação da conexão. 

Outro conjunto de abordagens tenta distinguir, de forma inteligente, entre as duas classes diferentes de 
perda: congestionamento e erros de bits. Existem dicas de que as perdas se devem ao congestionamento, 
como um aumento do RTT e a correlação entre perdas sucessivas. A marcação da notificação explícita 
de congestionamento (ECN - Explicit Congestion Notification) (ver Seção 6.4.2) também pode fornecer 
uma indicação de que o congestionamento é iminente, de modo que uma perda subsequente terá mais 
chances de estar relacionada ao congestionamento. Naturalmente, se você pode detectar a diferença entre 
os dois tipos de perda, então o TCP não precisa reduzir sua janela para perdas relacionadas a erros de bits. 
Infelizmente, é difícil determinar isso com 100% de precisão, e essa questão continua sendo uma área de 
pesquisa ativa. 
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6.3.2 Partida lenta 


O mecanismo de aumento aditivo que descrevemos é a técnica correta a usar quando a origem está 
operando próximo da capacidade disponível da rede, mas é necessário muito tempo para elevar a 
velocidade de uma conexão quando ela está começando do zero. Portanto, o TCP oferece um segundo 
mecanismo, ironicamente chamado de partida lenta,” que é usado para aumentar a janela de congestio- 
namento rapidamente na partida. A partida lenta efetivamente aumenta a janela de congestionamento 
exponencialmente, ao invés de linearmente. 

Especificamente, a origem começa definindo a JanelaCongestionamento como um pacote. Quando 
o ACKpara esse pacote é recebido, o TCP soma 1 à JanelaCongestionamento e depois envia dois pacotes. 
Ao receber os dois ACKs correspondentes, o TCP aumenta o valor de JanelaCongestionamento em 2 -um 
para cada ACK - e da próxima vez envia quatro pacotes. O resultado final é que o TCP efetivamente 
dobra o número de pacotes que existem na rede a cada RTT. A Figura 6.10 mostra o crescimento no 
número de pacotes na rede durante a partida lenta. Compare isso com o crescimento linear do aumento 
aditivo, ilustrado na Figura 6.8. 

A princípio, o motivo para um mecanismo exponencial ser chamado “lento” pode ser confuso, mas 
pode ser explicado se você se inserir no contexto histórico. Precisamos comparar a partida lenta não com 
o mecanismo linear da subseção anterior, mas com o comportamento original do TCP Considere o que 
acontece quando uma conexão é estabelecida e a origem começa a enviar pacotes, ou seja, quando atual- 
mente não existem pacotes na rede. Se a origem enviar tantos pacotes quantos forem permitidos pela 
janela anunciada — o que é exatamente o que o TCP fazia antes que a partida lenta fosse desenvolvida —, 
então mesmo que houvesse uma quantidade muito grande de largura de banda disponível na rede, os 
roteadores poderiam não ser capazes de consumir essa rajada de pacotes. Tudo depende de quanto 
espaço em buffer está disponível nos roteadores. A partida lenta, portanto, foi projetada para espaçar os 
pacotes de modo que essa rajada não ocorra. Em outras palavras, embora seu crescimento exponencial 
seja mais rápido do que o crescimento linear, a partida lenta é muito “mais lenta” do que enviar uma 
janela anunciada inteira de dados ao mesmo tempo. 


Origem Destino 





FIGURA 6.10 Pacotes em trânsito durante a partida lenta. 


“Embora o artigo original que descreve a partida lenta chame isso de “partida-lenta”, o termo sem o hífen é mais utilizado 
atualmente, e por isso omitimos o hífen aqui. 
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Na realidade, existem duas situações diferentes em que a partida lenta é executada. A primeira é 
no início de uma conexão, quando a origem não tem ideia de quantos pacotes poderão estar na rede 
em determinado momento. (Lembre-se que o TCP é executado sobre qualquer coisa, desde enlaces de 
9.600 bps até enlaces de 2,4 Gbps, de modo que não há como a origem saber a capacidade da rede.) 
Nessa situação, a partida lenta continua a dobrar a JanelaCongestionamento a cada RTT, até que haja 
uma perda, quando um evento de expiração do tempo limite ocasionará a diminuição multiplicativa, 
dividindo o valor deJanelaCongestionamento por 2. 

A segunda situação em que a partida lenta é usada é um pouco mais sutil; ela ocorre quando a conexão 
fica silenciosa enquanto espera a ocorrência de um evento de expiração do tempo limite. Lembre-se de 
como funciona o algoritmo de janela deslizante do TCP — quando um pacote é perdido, a origem por fim 
atinge um ponto onde enviou tantos dados quanto a janela anunciada permite, e por isso é bloqueada 
enquanto espera um ACK que não chegará. Por fim, o tempo limite é atingido, mas dessa vez não existem 
pacotes em trânsito, significando que a origem não receberá ACKs para programar a transmissão de 
novos pacotes. A origem, em vez disso, receberá um único ACK acumulado, que reabre a janela anunciada 
inteira, mas, conforme explicamos anteriormente, a origem utiliza a partida lenta para reiniciar o fluxo 
de dados, em vez de jogar uma janela inteira de dados na rede ao mesmo tempo. 

Embora a origem esteja usando a partida lenta novamente, ela agora sabe mais informações do que 
sabia no início de uma conexão. Especificamente, a origem possui um valor atual (e útil) de JanelaCon- 
gestionamento; esse é o valor de JanelaCongestionamento que existia antes da última perda de pacote, 
dividido por 2 como resultado da perda. Podemos pensar nisso como a janela de congestionamento 
alvo. A partida lenta é usada para aumentar rapidamente a taxa de envio para esse valor, e o aumento 
aditivo é usado desse ponto em diante. Observe que temos um pequeno problema de manutenção para 
cuidar, pois queremos nos lembrar da janela de congestionamento alvo resultante da diminuição multi- 
plicativa e também da janela de congestionamento real sendo usada pela partida lenta. Para resolver 
esse problema, o TCP introduz uma variável temporária para armazenar a janela alvo, normalmente 
chamada LimiarCongestionamento, cujo valor é igual ao valor da JanelaCongestionamento que resulta 
da diminuição multiplicativa. A variável JanelaCongestionamento, portanto, é reiniciada para um pacote, 
sendo incrementada em um pacote para cada ACK que é recebido, até atingir LimiarCongestionamento, 
quando então é incrementada em um pacote por RTT. 

Em outras palavras, o TCP aumenta a janela de congestionamento conforme definido pelo seguinte 
fragmento de código: 


fu int cw = estado->JanelaCongestionamento; 

uint incr = estado->maxseg; 

if (cw > estado->LimiarCongestionamento) 

incr = incr*incr/cw; 

estado->JanelaCongestionamento = MIN(cw + incr, TCP ) 


onde estado representa o estado de determinada conexão TCP e TCP MAXJAN define um limite superior 
até o qual o tamanho da janela de congestionamento pode crescer. 

A Figura 6.11 acompanha os aumentos e as diminuições da JanelaCongestionamento do TCP e serve 
para ilustrar a intercalação das fases de partida lenta e aumento aditivo / diminuição multiplicativa. Esse 
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FIGURA 6.11 Comportamento do controle de congestionamento TCP. Linha cinza curva =valor de JanelaCongestionamento com o 


passar do tempo; pontos sólidos no alto do gráfico — expirações do tempo limite; marcas de hachura no alto do gráfico= momento 
em que cada pacote é transmitido; barras verticais= momento da transmissão inicial de um pacote que, por fim, foi retransmitido. 





Capítulo 6 * Controle de congestionamento e alocação de recursos 311 


ELSEVIER 


gráfico foi obtido de uma conexão TCP real e mostra o valor atual da JanelaCongestionamento — a linha 
colorida — com o passar do tempo. 

Existem várias coisas a observar sobre esse gráfico. A primeira é o rápido aumento na janela de 
congestionamento no início da conexão. Isso corresponde à fase inicial de partida lenta. A fase de 
partida lenta continua até que vários pacotes sejam perdidos, em aproximadamente 0,4 segundo da 
conexão, quando a JanelaCongestionamento é aplanada em cerca de 34 KB. (O motivo para tantos 
pacotes serem perdidos durante a partida lenta será discutido a seguir.) O motivo para a janela de 
congestionamento aplanar é que não existem ACKs chegando, devido ao fato de que vários pacotes 
foram perdidos. De fato, nenhum pacote novo está sendo enviado durante esse momento, conforme 
indicado pela falta de marcas de hachura no alto do gráfico. Uma expiração do tempo limite por fim 
acontece em aproximadamente 2 segundos, quando a janela de congestionamento é dividida por 2 (ou 
seja, cortada de aproximadamente 34 KB para algo em torno de 17 KB) e LimiarCongestionamento é 
iniciado com esse valor. A partida lenta então faz com que a JanelaCongestionamento retorne para um 
pacote e comece a subir a partir daí. 

Não há detalhes suficientes no gráfico para ver exatamente o que acontece quando alguns pacotes 
são perdidos logo após 2 segundos, e por isso saltamos para o aumento linear na janela de congestio- 
namento que ocorre entre 2 e 4 segundos. Isso corresponde ao aumento aditivo. Em aproximadamente 
4 segundos, a JanelaCongestionamento aplana, novamente devido a um pacote perdido. Agora, em 
aproximadamente 5,5segundos: 


1. Umaexpiração do tempo limite acontece, fazendo com que a janela de congestionamento seja 
dividida por 2, passando de aproximadamente 22 KB para 11 KB, e LimiarCongestionamento é 
alterado para esse valor. 

2. JanelaCongestionamento retorna para um pacote, enquanto o emissor entra na partida lenta. 

3. A partida lenta faz com que JanelaCongestionamento cresça exponencialmente até atingir 
LimiarCongestionamento. 

4. JanelaCongestionamento passa a crescer linearmente. 


O mesmo padrão é repetido em aproximadamente 8 segundos, quando ocorre outra expiração do 
tempo limite. 

Agora, retornamos à questão de por que tantos pacotes são perdidos durante o período inicial de partida 
lenta. Nesse ponto, o TCP está tentando descobrir quanta largura de banda está disponível na rede. Essa é 
uma tarefa muito difícil. Se a origem não for agressiva nesse estágio — por exemplo, se só aumentar a janela de 
congestionamento linearmente -, então levará muito tempo para que ela descubra quanta largura de banda 
está disponível. Isso pode ter um grande impacto sobre a vazão alcançada por essa conexão. Por outro lado, se 
a origem for agressiva nesse estágio, como o TCP é durante o crescimento exponencial, então a origem corre 
o risco de ter uma quantidade de pacotes correspondente à metade de uma janela descartada pela rede. 

Para ver o que acontece durante o crescimento exponencial, considere a situação em que a origem 
acabou de enviar 16 pacotes com sucesso pela rede, fazendo com que ela dobre sua janela de conges- 
tionamento para 32. Porém, suponha que a rede tenha capacidade suficiente para admitir 16 pacotes 
provenientes dessa origem. O resultado provável é que 16 dos 32 pacotes enviados sob a nova janela 
de congestionamento serão descartados pela rede; na realidade, esse é o pior resultado possível, pois 
alguns dos pacotes serão mantidos no buffer de algum roteador. Esse problema se tornará cada vez 
mais severo à medida que o produto atraso x largura de banda das redes aumentar. Por exemplo, um 
produto atraso X largura de banda de 500 KB significa que cada conexão tem o potencial de perder até 
500 KB de dados no início de cada conexão. Naturalmente, isso considera que a origem e o destino 
implementam a extensão de “janelas grandes”. 

Alguns projetistas de rede propuseram alternativas à partida lenta, nas quais a origem tenta estimar a 
largura de banda disponível por meios mais inteligentes. Um exemplo recente é o mecanismo de partida 
rápida que está passando por processo de padronização junto à IETF A ideia básica é que um emissor 
TCP pode pedir uma taxa de transmissão inicial maior do que a partida lenta permitiria, colocando uma 
taxa solicitada em seu pacote SYN como uma opção do IP Os roteadores ao longo do caminho podem 
examinar a opção, avaliar o nível de congestionamento atual no enlace de saída para esse fluxo e decidir 
se essa taxa é aceitável, se uma taxa mais baixa seria aceitável ou se a partida lenta padrão deverá ser 


312 REDES DE COMPUTADORES ELSEVIER 


usada. Quando o SYN chegar ao receptor, ele conterá uma taxa que foi aceitável a todos os roteadores no 
caminho ou uma indicação de que um ou mais roteadores no caminho não puderam aceitar a solicitação 
de partida rápida. No primeiro caso, o emissor TCP usa essa taxa para iniciar a transmissão; no outro 
caso, ele deve usar a partida lenta padrão. Se o TCP tiver permissão para começar a enviar pacotes em 
uma taxa mais alta, uma sessão poderá alcançar mais rapidamente o ponto de encher o tubo, ao invés 
de exigir muitos tempos de ida e volta para fazer isso. 

Naturalmente, um dos desafios desse tipo de melhoria no TCP é que isso exige muito mais cooperação 
dos roteadores do que o TCP padrão. Se um único roteador no caminho não tiver suporte ao mecanismo 
de partida rápida, então o sistema volta à partida lenta padrão. Assim, pode levar muito tempo antes 
que esses tipos de melhorias sejam usados na Internet; por enquanto, elas provavelmente serão mais 
usadas em ambientes de rede controlados (por exemplo, em redes de pesquisa). 


6.3.3 Retransmissão rápida e recuperação rápida 


Os mecanismos descritos até aqui fizeram parte da proposta original para acrescentar o controle 
de congestionamento ao TCP Porém, logo se descobriu que a implementação esparsa dos eventos de 
expiração do tempo limite do TCP ocasionava longos períodos de tempo durante os quais a conexão 
ficava silenciosa enquanto aguardava um temporizador expirar. Por causa disso, um novo mecanismo, 
chamado retransmissão rápida, foi acrescentado ao TCP A retransmissão rápida é uma heurística que 
algumas vezes dispara a retransmissão de um pacote descartado mais cedo do que um mecanismo 
de expiração do tempo limite normal. O mecanismo de retransmissão rápida não substitui os eventos 
regulares de expiração do tempo limite; ele apenas melhora essa funcionalidade. 

A ideia da retransmissão rápida é simples. Toda vez que um pacote de dados chega ao lado receptor, 
este responde com uma confirmação, mesmo que esse número de sequência já tenha sido confirmado. 
Assim, quando um pacote chega fora de ordem — ou seja, o TCP ainda não pode confirmar os dados que 
o pacote contém, porque os dados anteriores ainda não chegaram —, o TCP emite novamente a mesma 
confirmação que enviou da última vez. Essa segunda transmissão da mesma confirmação é chamada 
ACK duplicado. Quando o lado emissor encontra um ACK duplicado, ele sabe que o outro lado deve ter 
recebido um pacote fora de ordem, o que sugere que um pacote anterior pode ter sido perdido. Como 
também é possível que o pacote anterior apenas esteja atrasado, e não perdido, o emissor espera até 
receber algum número de ACKs duplicados e depois retransmite o pacote que falta. Na prática, o TCP 
espera até ter visto três ACKs duplicados antes de retransmitir o pacote. 

A Figura 6.12 ilustra como os ACKs duplicados ocasionam uma retransmissão rápida. Neste exem- 
plo, o destino recebe os pacotes 1 e 2, mas o pacote 3 foi perdido na rede. Assim, o destino enviará 


Emissor Receptor 
Pacote 1 
Pacote 2 
Pacote 3 aco ACK 1 
Pacote 4 ACK 2 
Pacote 5 ACK 2 
Pacote 6 
ACK 2 
ACK 2 
Retransmite 
Pacote 3 
ACK 6 


FIGURA 6.12 Retransmissão rápida baseada em ACKs duplicados. 





Capítulo 6 ° Controle de congestionamento e alocação de recursos 313 





ES Mas 
ELSEVIE 


e 

70 TI! AO NAO eae oca ra EA 
60 

50 

40 

30 

20 | 

10 


kB 





T T T T 1 


T T 
1,0 2,0 3,0 4,0 5,0 6,0 7,0 
Tempo (segundos) 
FIGURA 6.13 Gráfico do TCP com retransmissão rápida. Linha cinza curva=valor de JanelaCongestionamento; pontos 


sólidos=expirações do tempo limite; marcas de hachura= momento em que cada pacote é transmitido; barras verticais= momento da 
transmissão inicial de um pacote que por fim foi retransmitido. 


um ACK duplicado para o pacote 2 quando o pacote 4 chegar, novamente quando o pacote 5 chegar, 
e assim por diante. (Para simplificar este exemplo, pensamos em termos de pacotes 1, 2, 3 etc., em 
vez de nos preocuparmos com números de sequência para cada byte.) Quando o emissor recebe o 
terceiro ACK duplicado para o pacote 2 — aquele enviado porque o receptor recebeu o pacote 6 —, ele 
retransmite o pacote 3. Observe que, quando a cópia retransmitida do pacote 3 chega ao destino, 
o receptor envia um ACK acumulado para todos os pacotes até (e incluindo) o pacote 6, de volta 
à origem. 

A Figura 6.13 ilustra o comportamento de uma versão do TCP com o mecanismo de retransmissão 
rápida. É interessante compararmos esse gráfico com aquele da Figura 6.11, no qual a retransmissão 
rápida não está implantada — foram eliminados os períodos longos durante os quais a janela de conges- 
tionamento permanece plana e nenhum pacote é enviado. Em geral, essa técnica é capaz de eliminar 
cerca de metade dos eventos esparsos de expiração do tempo limite em uma conexão TCP típica, 
resultando em uma melhoria de aproximadamente 20% na vazão em relação ao que poderia ter sido 
alcançado. Porém, observe que a estratégia de retransmissão rápida não elimina os eventos esparsos 
de expiração do tempo limite. Isso porque, para um tamanho de janela pequeno, não haverá pacotes 
suficientes em trânsito para fazer com que ACKs duplicados suficientes sejam entregues. Com pacotes 
perdidos suficientes — por exemplo, como acontece durante a fase de partida lenta inicial —, o algoritmo 
de janela deslizante por fim bloqueia o emissor até que o tempo limite seja atingido. Dado o tamanho 
máximo atual de 64 KB para a janela anunciada, na prática o mecanismo de retransmissão rápida do 
TCP é capaz de detectar até três pacotes descartados por janela. 

Finalmente, há uma última melhoria que podemos fazer. Quando o mecanismo de retransmissão 
rápida sinaliza o congestionamento, em vez de descartar a janela de congestionamento para um pacote 
e executar a partida lenta, é possível usar os ACKs que ainda estão no tubo para temporizar o envio de 
pacotes. Esse mecanismo, que é chamado recuperação rápida, efetivamente remove a fase de partida 
lenta que acontece entre o momento em que a retransmissão rápida detecta um pacote perdido e o 
início do aumento aditivo. Por exemplo, a recuperação rápida evita o período de partida lenta entre 3,8 
e 4 segundos na Figura 6.13 e, em vez disso, simplesmente reduz a janela de congestionamento pela 
metade (de 22 KB para 11 KB) e retoma o aumento aditivo. Em outras palavras, a partida lenta só é 
usada no início de uma conexão e sempre que ocorre um evento esparso de expiração do tempo limite. 
Em todos os outros momentos, a janela de congestionamento está seguindo um padrão puramente de 
aumento aditivo /diminuição multiplicativa. 


UM TCP MAIS RÁPIDO? 





Por várias vezes nas duas últimas décadas, o argumento sobre a velocidade que o TCP pode alcançar 
retornou à tona. Primeiro, havia a afirmação de que o TCP era muito complexo para que pudesse ser 
executado rapidamente no software do host enquanto as redes caminhavam para a faixa do gigabit. Essa 
afirmação foi repetidamente invalidada. Porém, mais recentemente, um resultado teórico importante 
mostrou que existem limites sobre como o TCP pode funcionar em ambientes com produtos atraso x largura 
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de banda muito altos. Uma análise do comportamento do controle de congestionamento do TCP mostrou 
que, quando ele entra em regime, a vazão do TCP é aproximadamente 


1,2x MSS 
RTT x Jp 


Em uma rede com um RTT de 100 ms e enlaces de 10 Gbps, segue-se que uma única conexão TCP só será 
capaz de alcançar uma vazão próxima da velocidade do enlace se a taxa de perda estiver abaixo de um a cada 
5 bilhões de pacotes — equivalente a um evento de congestionamento a cada 100 minutos. Até mesmo perdas 
de pacote muito raras, devido a erros de bits na fibra, normalmente produzirão uma taxa de perda muito 
mais alta do que isso, tornando impossível preencher o tubo com uma única conexão TCP. 

Diversas propostas para melhorar o comportamento do TCP em redes com produtos atraso X largura de 
banda muito altos foram feitas, e elas variam do incremental ao drástico. Observando a dependência em 
relação ao MSS, uma mudança simples que foi proposta é aumentar o tamanho do pacote. Infelizmente, 
aumentar tamanhos de pacote também aumenta as chances de que determinado pacote sofra um erro 
de bit, de modo que, em algum ponto, aumentar apenas o MSS pode não ser suficiente. Outras propostas 
que foram desenvolvidas na IETF e em outros lugares fazem mudanças na maneira como o TCP evita o 
congestionamento, em uma tentativa de tornar o TCP mais capaz de usar a largura de banda disponível. Os 
desafios aqui são ser justo com as implementações do TCP padrão e também evitar os problemas de colapso 
por congestionamento que levaram ao comportamento atual do TCP. 

A proposta do HighSpeed TCP agora um RFC experimental, torna o TCP mais agressivo apenas quando 
está claramente operando em um ambiente com produto atraso x largura de banda muito alto e não 
competindo com muito tráfego. Basicamente, quando a janela de congestionamento fica muito grande, 

o HighSpeed TCP começa a aumentar o valor de JanelaCongestionamento por uma quantidade maior do 
que o TCP padrão. No ambiente normal onde JanelaCongestionamento é relativamente pequena (cerca 

de 40 x MSS), o HighSpeed TCP é semelhante ao TCP padrão. Muitas outras propostas foram feitas nesse 
sentido, algumas listadas na seção “Leitura adicional”. Notavelmente, o comportamento do TCP padrão no 
sistema operacional Linux agora é baseado em uma variante do TCP chamada CUBIC, que também expande 
a janela de congestionamento agressivamente em regimes de alto produto atraso x largura de banda, 
enquanto mantém compatibilidade com variantes do TCP mais antigas em ambientes com largura de banda 
mais restrita. 

A proposta Quick-Start, que muda o comportamento de partida do TCP foi mencionada anteriormente. 
Como ela pode permitir que uma conexão TCP aumente sua taxa de transmissão mais rapidamente, seu 
efeito sobre o desempenho do TCP é mais observável quando as conexões são curtas, ou quando uma 
aplicação termina periodicamente de enviar dados e o TCP de outra forma retornaria para a partida lenta. 

Outra proposta — FAST TCP — usa um método semelhante ao TCP Vegas, descrito na próxima seção. A 
ideia básica é antecipar o começo do congestionamento e evitá-lo, de forma a não causar o impacto sobre o 
desempenho associado com a diminuição da janela de congestionamento. 

Várias propostas que envolvem mudanças mais drásticas no TCP ou ainda a sua substituição por um 
novo protocolo, também foram desenvolvidas. Estas possuem um potencial considerável de preencher 
o tubo de forma rápida e justa em ambientes com alto produto atraso x largura de banda, mas também 
enfrentam desafios de implantação mais altos. O leitor deverá consultar as referências ao final deste capítulo 
para descobrir o trabalho em andamento nessa área. 


Taxa= 





6.4 Mecanismos para impedir o congestionamento 


É importante entender que a estratégia do TCP é controlar o congestionamento quando eleacontece, 
em vez de tentar evitar o congestionamento em primeiro lugar. De fato, o TCP aumenta repetidamente 
a carga que ele impõe sobre a rede em um esforço para encontrar o ponto em que o congestionamento 
ocorre, e depois recua a partir desse ponto. Em outras palavras, o TCP precisa criar perdas para encon- 
trar a largura de banda disponível da conexão. Uma alternativa atraente, mas que ainda não foi muito 
adotada, é prever quando um congestionamento está para acontecer e depois reduzir a taxa em que os 
hosts enviam dados, imediatamente antes que os pacotes comecem a ser descartados. Chamamos essa 
estratégia de prevenção de congestionamento, para distingui-la do controle de congestionamento. 
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Esta seção descreve três mecanismos diferentes para prevenir o congestionamento. Os dois primeiros 
utilizam uma técnica semelhante: eles colocam alguma funcionalidade adicional no roteador para 
ajudar o nó final na antecipação do congestionamento. O terceiro mecanismo é bem diferente dos dois 
primeiros: ele tenta evitar o congestionamento envolvendo apenas os nós finais. 


6.4.1 DECbit 


O primeiro mecanismo foi desenvolvido para uso na arquitetura de rede digital (DNA - Digital Network 
Architecture), uma rede sem conexões com um protocolo de transporte orientando a conexão. Esse meca- 
nismo, portanto, também poderia ser aplicado ao TCP e ao IP Como já observamos, a ideia aqui é dividir 
de modo mais uniforme a responsabilidade pelo controle de congestionamento entre os roteadores e 
os nós finais. Cada roteador monitora a carga que está experimentando e notifica explicitamente os nós 
finais quando o congestionamento estiver para ocorrer. Essa notificação é implementada definindo-se 
um bit de congestionamento binário nos pacotes que fluem pelo roteador; daí o nome DEChit. O 
host de destino, então, copia esse bit de congestionamento para o ACK, que o envia de volta à origem. 
Finalmente, a origem ajusta sua taxa de transmissão de modo a evitar o congestionamento. A discussão 
a seguir descreve o algoritmo com mais detalhes, começando com o que acontece no roteador. 

Um único bit de congestionamento é acrescentado ao cabeçalho do pacote. Um roteador coloca o 
valor desse bit em 1em um pacote se seu tamanho médio de fila for maior ou igual a 1 no momento em 
que o pacote chega. Esse tamanho médio de fila é medido considerando um intervalo de tempo que 
cobre o último ciclo ocupado + ocioso mais o ciclo ocupado atual. (O roteador está ocupado quando 
está transmitindo, e ocioso quando não o está.) A Figura 6.14 mostra o tamanho da fila em um roteador 
como uma função do tempo. Basicamente, o roteador calcula a área sob a curva e divide esse valor pelo 
intervalo de tempo para calcular o tamanho médio da fila. Usar um tamanho de fila igual a 1 como gatilho 
para ativar o bit de congestionamento é uma escolha que busca o equilíbrio entre um enfileiramento 
significativo (e, portanto, vazão mais alta) e um maior tempo ocioso (e, portanto, atraso mais baixo). 
Em outras palavras, um tamanho de fila 1 parece otimizar a função de potência. 

Agora, voltando nossa atenção para a parte que se refere ao host desse mecanismo, a origem regis- 
tra quantos de seus pacotes resultaram em algum roteador ativando o bit de congestionamento. Em 
particular, a origem mantém uma janela de congestionamento, assim como no TCP e observa que 
fração da última janela de pacotes resultou no bit sendo ativado. Se menos de 50% dos pacotes teve o 
bit ativado, então a origem aumenta sua janela de congestionamento em um pacote. Se 50% ou mais 
da última janela de pacotes teve o bit de congestionamento ativado, então a origem diminui sua janela 
de congestionamento para 0,875 vezes o valor anterior. O valor 50% foi escolhido como limiar com 
base na análise que mostrou que ele corresponde ao pico da curva de potência. A regra “aumentar 
em 1, diminuir em 0,875” foi escolhida porque o aumento aditivo/diminuição multiplicativa torna o 
mecanismo estável. 


Tamanho da fila 
A 


Hora 
atual 











Tempo 
Ciclo Ciclo 
anterior ps atual a 
Intervalo 
médio 


FIGURA 6.14 Calculando o tamanho médio da fila em um roteador. 
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6.4.2 Detecção aleatória antecipada (RED) 


Um segundo mecanismo, chamado detecção aleatória antecipada (RED — Random Early Detection), 
é semelhante ao esquema DECbit, em que cada roteador é programado para monitorar seu próprio 
tamanho de fila e, quando ele detecta que o congestionamento é iminente, notifica a origem para ajustar 
sua janela de congestionamento. A técnica de RED, inventada por Sally Floyd e Van Jacobson no início 
da década de 1990, difere do esquema DECbit de duas maneiras principais. 

A primeira é que, em vez de enviar explicitamente uma mensagem de notificação de congestiona- 
mento à origem, a técnica de RED normalmente é implementada de modo que notifique implicitamente 
a origem do congestionamento, descartando um de seus pacotes. A origem, portanto, é efetivamente 
notificada pelo evento subsequente de expiração do tempo limite ou ACK duplicado. Caso você ainda 
não tenha adivinhado, o mecanismo de RED foi projetado para ser usado em conjunto com o TCP que 
atualmente detecta o congestionamento por meio da expiração do tempo limite(ou algum outro meio 
de detectar a perda de pacotes, como ACKs duplicados). Como a parte “antecipada” do acrônimo RED 
sugere, o gateway descarta o pacote antes do que seria necessário, de modo a notificar a origem de que 
ela deve diminuir sua janela de congestionamento mais cedo do que normalmente faria. Em outras 
palavras, o roteador descarta alguns pacotes antes que tenha esgotado seu espaço de buffer com- 
pletamente, para que a origem opere mais devagar, esperando que, com isso, ele não precise descartar 
muitos pacotes mais tarde. Observe que o RED poderia facilmente ser adaptado para operar em conjunto 
com um esquema de feedback explícito simplesmente marcando um pacote em vez de descartando-o, 
conforme discutiremos na nota sobre notificação explícita de congestionamento (Explicit Congestion 
Notification — ECN). 


NOTIFICAÇÃO EXPLÍCITA DE CONGESTIONAMENTO (ECN) 


Embora as implantações atuais de RED quase sempre sinalizem o congestionamento pelo descarte de pacotes, 
recentemente tem-se dado muita atenção à questão sobre a notificação explícita ser ou não uma estratégia 
melhor. Isso levou a um esforço para padronizar a ECN (Explicit Congestion Notification) para a Internet. 

O argumento básico é que, embora o descarte de um pacote certamente atue como um sinal de 
congestionamento e provavelmente é a coisa certa a fazer para transmissões em massa de longa duração, isso 
atrapalha as aplicações que são sensíveis ao atraso ou à perda de um ou mais pacotes. Aplicações de tráfego 
interativo como o Telnet e a navegação na Web são exemplos notáveis. A descoberta do congestionamento 
através da notificação explícita é mais apropriada para tais aplicações. 

Tecnicamente, a ECN exige 2 bits; o padrão proposto usa os bits 6 e 7 no campo TOS do IP Um é 
fixado em lpela origem para indicar que é capaz de usar ECN, ou seja, capaz de reagir à notificação de 
congestionamento. O outro é colocado em Ipelos roteadores ao longo do caminho fim a fim quando o 
congestionamento é encontrado. Esse último bit também é ecoado de volta à origem pelo host de destino. O 
TCP executando na origem responde ao bit ECN marcado exatamente da mesma maneira como responde a 
um pacote descartado. 

Como em qualquer boa ideia, esse foco recente sobre a ECN fez com que as pessoas parassem e pensassem 
a respeito de outras maneiras como as redes podem se beneficiar com uma troca de informações no estilo ECN 
entre os hosts na borda das redes e os roteadores no meio da rede, usando mecanismos de carona nos pacotes 
de dados. A estratégia geral é por vezes chamada gerenciamento ativo de filas, e a pesquisa recente parece 
indicar que ele é particularmente valioso para fluxos TCP que tenham grandes produtos atraso x largura de 
banda. O leitor interessado poderá procurar as referências relevantes dadas no final do capítulo. 





A segunda diferença entre RED e DECbit está nos detalhes de como a RED decide quando descartar 
um pacote e qual pacote ele decide descartar. Para entender a ideia básica, considere uma fila FIFO 
simples. Em vez de esperar que a saída fique completamente cheia e depois ser forçado a descartar 
cada pacote que chega (a política de descarte da cauda, da Seção 6.2.1), poderíamos decidir descartar 
cada pacote que chega com alguma probabilidade de descarte sempre que o tamanho da fila ultrapassar 
algum nível de descarte. Essa ideia é chamada descarte aleatório antecipado. O algoritmo RED define os 
detalhes de como monitorar o tamanho da fila e quando descartar um pacote. 
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Nos parágrafos seguintes, descrevemos o algoritmo RED conforme proposto originalmente por Floyd 
e Jacobson. Observamos que várias modificações desde então foram propostas pelos inventores e por 
outros pesquisadores; algumas destas são discutidas na seção Leitura adicional. Contudo, as ideias 
principais são as mesmas que aquelas apresentadas a seguir, e a maioria das implementações atuais 
semelhanto ao algoritmo seguinte. 

Primeiro, o algoritmo deRED calcula um tamanho médio de fila usando uma média móvel ponderada se- 
melhante àquela usada no cálculo do tempo limite original do TCP Ou seja, TamMédio é calculado como 


TamMédio = (1 — Peso) x TamMédio + Peso x TamAmostra 


onde 0 <Peso< 1 e TamAmostra é o tamanho da fila quando é feita uma amostra é medida. Na maior 
parte das implementaçõesem software, o tamanho da fila é medido toda vez que um novo pacote chega 
ao gateway. Em hardware, ele poderia ser calculado em algum intervalo fixo de amostragem. 

O motivo para o uso de um tamanho de fila móvel, em vez de um instantâneo, é que ele captura com 
mais precisão a noção de congestionamento. Devido à natureza em rajada do tráfego da Internet, as filas 
podem ficar cheias muito rapidamente e, depois, esvaziar-se novamente. Se uma fila estiver passando 
a maior parte do seu tempo vazia, então provavelmente não é apropriado concluir que o roteador está 
congestionado e pedir que os hosts reduzam sua velocidade de transmissão. Assim, o cálculo da média 
móvel ponderada tenta detectar o congestionamento de longa duração, conforme indicado na parte 
direita da Figura 6.15, filtrando as mudanças de curto prazo no tamanho da fila. Você pode pensar 
na média móvel como um filtro passa-baixas, onde o Peso determina a constante de tempo do filtro. 
A questão de como escolhemos essa constante de tempo é discutida a seguir. 

Em segundo lugar, o mecanismo de RED possui dois limiares de tamanho de fila que disparam certa 
atividade: LimiarMínimoe LimiarMáximo. Quando um pacote chega ao gateway, o algoritmo de RED 
compara o TamMédio atual com esses dois limiares, de acordo com as seguintes regras: 


seTamMédiosLimiarMínimo 

=>enfileira o pacote 
seLimiarMínimo <TamMédio<LimiarMáximo 

calcula probabilidade P 

—sdescarta o pacote que chega com probabilidade P 
seLimiarMáximo <TamMédio 

descarta o pacote que chega 


Ou seja, se o tamanho médio da fila for menor do que o limiar inferior, nenhuma ação é tomada, e 
se o tamanho médio da fila for maior que o limiar superior, então o pacote sempre é descartado. Se o 
tamanho médio da fila estiver entre os dois limiares, então o pacote recém-chegado é descartado com 
alguma probabilidade P Essa situação é representada na Figura 6.16. O relacionamento aproximado entre 
P e TamMédio aparece na Figura 6.17. Observe que a probabilidade de descarte aumenta lentamente 
quando TamMédio está entre os dois limiares, atingindo MaxP no limiar superior, ponto em que salta 
para a unidade. O raciocínio por trás disso é que se TamMédio atinge o limiar superior, então a técnica 
mais suave (descartar alguns pacotes) não está funcionando e medidas drásticas são exigidas, ou seja, 
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FIGURA 6.16 Limiares do mecanismo 
FIGURA 6.15 Tamanho da fila pela média móvel ponderada. de RED em uma fila FIFO. 
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descartar todos os pacotes que chegam. Algumas pesquisas sugeriram que uma transição mais suave 
do descarte aleatório para o descarte completo, em vez da técnica descontínua mostrada aqui, pode 
ser apropriada. 

Embora a Figura 6.17 mostre a probabilidade de descarte como uma função apenas de TamMédio, 
a situação na realidade é um pouco mais complicada. Na realidade, P é uma função de TamMédio e 
do tempo decorrido desde que o último pacote foi descartado. Especificamente, ele é calculado da 
seguinte maneira: 


PTemp = MaxP x (TamMédio — LimiarMínimo)/(LimiarMáximo — LimiarMínimo) 
P = PTemp/(1 — contador x PTemp) 


PTemp é a variável que é representada no eixo y da Figura 6.17, contador registra quantos pacotes 
recém-chegados foram enfileirados (não descartados), enquanto TamMédio fica entre os dois limiares. P 
aumenta lentamente enquanto contador aumenta, tornando assim um descarte cada vez mais provável 
à medida que aumenta o tempo desde o último descarte. Isso faz com que descartes pouco espaçados 
sejam relativamente menos prováveis do que os descartes mais espaçados. Essa etapa extra no cálculo 
de P foi introduzida pelos inventores da técnica de RED quando observaram que, sem isso, os descartes de 
pacote não eram bem distribuídos no tempo, mas costumavam ocorrer em grupos. Como as chegadas 
de pacote de certa conexão provavelmente ocorrem em rajadas, esse agrupamento de descartes causa 
vários descartes em uma única conexão. Isso não é desejável, pois somente um descarte por tempo de 
ida e volta é suficiente para fazer com que uma conexão reduza seu tamanho de janela, enquanto vários 
descartes poderiam levá-la de volta a uma partida lenta. 

Como exemplo, suponha que tenhamos definido o MaxP como 0,02 e contador seja inicializado em 
0. Se o tamanho médio da fila fosse a metade entre os dois limiares, então PTemp e o valor inicial de P 
seriam metade de MaxP, ou 0,01. Um pacote que chega, é claro, tem uma chance de 99 em 100 de entrar 
na fila nesse ponto. A cada pacote sucessivo que não é descartado, P diminui lentamente, e quando 50 
pacotes tiverem chegado sem que tenha havido um descarte, P terá dobrado para 0,02. No evento im- 
provável de que 99 pacotes cheguem sem perda, P alcança o valor1, garantindo que o próximo pacote 
será descartado. O importante a respeito dessa parte do algoritmo é que ele garante uma distribuição 
mais ou menos uniforme dos descartes ao longo do tempo. 

Espera-se que, se o algoritmo de RED descartar uma pequena porcentagem dos pacotes quando 
TamMédio exceder LimiarMínimo, o efeito será fazer com que algumas conexões TCP reduzam seus 
tamanhos de janela, o que por sua vez reduzirá a taxa em que os pacotes chegam no roteador. Tudo 
correndo bem, TamMédio diminuirá e o congestionamento será evitado. O tamanho da fila pode ser 
mantido pequeno, enquantoa vazão permanece alta, pois poucos pacotes são descartados. 

Observe que, como o algoritmo de RED está operando sobre uma média temporal do tamanho da 
fila, é possível que o tamanho instantâneo da fila seja muito maior que TamMédio. Nesse caso, se um 
pacote chegar e não houver lugar para colocá-lo, então ele terá de ser descartado. Quando isso acontece, 
o algoritmo de RED está operando no modo de descarte da cauda. Um dos objetivos da técnica de RED 
é evitar o comportamento de descarte da cauda, se possível. 
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A natureza aleatória da técnica de RED confere uma propriedade interessante ao algoritmo. Como 
a RED descarta pacotes aleatoriamente, a probabilidade de que o algoritmo de REDdecida descartar 
o(s) pacote(s) de um fluxo qualquer é mais ou menos proporcional ao compartilhamento da largura de 
banda que esse fluxo está obtendo atualmente nesse roteador. Isso porque um fluxo que está enviando 
um número relativamente grande de pacotes está oferecendo mais candidatos para o descarte aleatório. 
Assim, há algum sentido de alocação justa de recursos embutida na RED, embora de forma alguma ela 
seja exata. 


Observe que uma quantidade considerável de análise foi empregada na definição de diversos parâmetros 
da técnica de RED - por exemplo, LimiarMáximo, LimiarMínimo, MAxP e Peso -, tudo em nome da 
otimização da função de potência (razão entre vazão e atraso). O desempenho desses parâmetros também 
foi confirmado via simulação, e o algoritmo provou-se não ser demasiadamente sensível a eles. Porém, é 


importante ter em mente que toda essa análise e simulação dependem de uma caracterização específica da 
carga de trabalho da rede. A contribuição real da RED é um mecanismo pelo qual o roteador pode gerenciar 
seu tamanho de fila com mais precisão. Definir exatamente o que constitui um tamanho de fila ideal 
depende das características de tráfego e ainda é assunto para pesquisa, com informações reais agora sendo 
colhidas da implantação operacional da RED na Internet. 





Considere a definição de dois limiares, LimiarMínimo e LimiarMáximo. Se o tráfego for principal- 
mente em rajadas, então LimiarMínimo deverá ser suficientemente grande para permitir que a utilização 
do enlace seja mantida em um nível aceitavelmente alto. Além disso, a diferença entre os dois limiares 
deverá ser maior que o aumento típico no tamanho médio da fila em um RTT. A definição de LimiarMá- 
ximo como o dobro de LimiarMínimo parece ser uma regra prática razoável, dada as características do 
tráfego na Internet atualmente. Além disso, como esperamos que o tamanho médio da fila fique entre os 
dois limiares durante os períodos de muita carga, deverá haver espaço livre suficiente no buffer acima 
de LimiarMáximo para absorver as rajadas naturais que ocorrem no tráfego da Internet, sem forçar o 
roteador a entrar no modo de descarte da cauda. 

Observamos, conforme exposto, que Peso determina a constante de tempo para a média móvel 
do filtro passa-baixas, e isso nos dá uma dica sobre como poderíamos escolher um valor adequado 
para ele. Lembre-se que a técnica de RED está tentando enviar sinais aos fluxos TCP ao descartar 
pacotes durante momentos de congestionamento. Suponha que um roteador descarte um pacote de 
alguma conexão TCP e depois encaminhe imediatamente mais alguns pacotes da mesma conexão. 
Quando esses pacotes chegarem ao receptor, ele começa a enviar ACKs duplicados para o emissor. 
Quando o emissor encontrar ACKs duplicados suficientes, ele reduzirá o tamanho da janela. Assim, 
desde o momento em que o roteador descarta um pacote até o momento em que o mesmo roteador 
começa a ver algum alívio na conexão afetada em termos de um tamanho de janela reduzido, pelo 
menos um tempo de ida e volta precisa se passar para essa conexão. Provavelmente, não há muito 
sentido em fazer com que o roteador responda ao congestionamento em escalas de tempo muito 
menores do que o tempo de ida e volta das conexões que passam por ele. Como vimos anteriormente, 
100 ms não é uma estimativa ruim dos tempos de ida e volta médios na Internet. Assim, Peso deve 
ser escolhido de modo a filtrar as mudanças temporais no tamanho da fila de duração muito menor 
do que 100 ms. 

Como a RED funciona enviando sinais aos fluxos TCP para lhes pedir que diminuam a velocidade, 
você poderia perguntar o que aconteceria se esses sinais fossem ignorados. Isso normalmente é cha- 
mado de problema de fluxo não responsivo, e tem sido uma questão de preocupação há vários anos. 
Os fluxos não responsivos usam mais do que sua “fatia justa” dos recursos da rede e poderiam causar 
um colapso de congestionamento se houvesse muitos deles, assim como nos dias antes do controle de 
congestionamento do TCP. Algumas das técnicas descritas na Seção 6.5 podem ajudar com esse pro- 
blema, isolando certas classes do tráfego de outras. Há também a possibilidade de que uma variante 
da RED possa descartar mais intensamente pacotes de fluxos que não são responsivos às advertências 
iniciais que ele envia; isso continua a ser uma área de pesquisa ativa. 
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6.4.3 Prevenindo o congestionamento com base na origem 


Ao contrário dos dois esquemas de prevenção de congestionamento anteriores, que dependiam de novos 
mecanismos nos roteadores, agora descrevemos uma estratégia para detectar os estágios incipientes 
de congestionamento — antes que ocorram perdas — a partir dos hosts finais. Primeiro, daremos uma 
rápida visão geral de uma coleção de mecanismos relacionados, que utilizam informações diferentes 
para detectar os primeiros estágios do congestionamento, e depois descreveremos um mecanismo 
específico com alguns detalhes. 

A ideia geral dessas técnicas é observar algum sinal na rede de que a fila de algum roteador está 
crescendo e que o congestionamento acontecerá logo se nada for feito a respeito disso. Por exemplo, a 
origem poderia observar que, enquanto as filas de pacotes crescem nos roteadores da rede, existe um 
aumento mensurável no RTT para cada pacote sucessivo que é transmitido. Um algoritmo em particular 
explora essa observação da seguinte maneira: a janela de congestionamento normalmente aumenta 
como no TCP mas a cada dois atrasos de ida e volta o algoritmo verifica se o RTT atual é maior do que 
a média dos RT'Ts mínimo e máximo observados até aqui. Se for o caso, então o algoritmo diminui a 
janela de congestionamento em um oitavo. 

Um segundo algoritmo faz algo semelhante. A decisão quanto a se o tamanho da janela deve ou não 
ser mudado é baseada nas mudanças no RTT e no tamanho da janela. A janela é ajustada uma vez a 
cada dois atrasos de ida e volta, com base no produto 


(JanelaAtual — JanelaAntiga) x (RTTAtual — RTTAntigo) 


TAHOE, RENO EVEGAS 


O nome “TCP Vegas” refere-se a uma variante das primeiras implementações do TCP que foram distribuídas nas 
versões do BSD Unix 4.3. Essas versões eram conhecidas como Tahoe e Reno (que, como Las Vegas, são lugares 
no estado americano de Nevada), e as versões do TCP tornaram-se conhecidas pelos nomes da distribuição BSD. 
O TCP Tahoe, que também é conhecido como BSD Network Release 1.0 (BNR1), corresponde à implementação 
original do mecanismo de controle de congestionamento de Jacobson, e inclui todos os mecanismos descritos 
na Seção 6.3, exceto a recuperação rápida. O TCP Reno, que também é conhecido como BSD Network Release 2.0 
(BNR2), acrescenta o mecanismo de recuperação rápida, junto com uma otimização conhecida como previsão 
de cabeçalho — otimização para o caso comum em que os segmentos chegam em ordem. O TCP Reno também 
tem suporte ao atraso de ACKs — envio de confirmações a cada dois segmentos, em vez de a cada segmento —, 
embora esse seja um mecanismo opcional que às vezes é desativado. Uma versão mais recente do TCP 
distribuída no BSD Unix 4.4, acrescenta as extensões de “janelas grandes”, descritas na Seção 5.2. 

Com a crescente popularidade do sistema operacional Linux, e um aumento no número de pesquisadores 
examinando o controle de congestionamento do TCP a situação se tornou muito mais complexa. O Linux hoje 
oferece uma gama de opções para controle de congestionamento do TCP com Vegas sendo uma opção e uma 
variante mais nova, chamada TCP CUBIC, sendo o padrão. A ideia geral de usar nomes de lugar para se referir 
às variantes do TCP tem sido adotada com entusiasmo (ver TCP-Illinois e TCP-Westwood, por exemplo). 

Um ponto que você deverá guardar desta discussão sobre a linhagem do TCP é que o TCP tem sido um 
protocolo um tanto fluido no decorrer dos últimos anos, especialmente em seu mecanismo de controle 
de congestionamento. De fato, você nem sequer encontraria um acordo universal sobre qual técnica foi 
introduzida em qual versão, devido à disponibilidade de versões intermediárias do código e o fato de patches 
terem sido adicionados sobre patches. 

Tudo o que pode ser dito com toda certeza é que duas implementações quaisquer de TCP que sigam as 
especificações originais, embora devam interoperar, não necessariamente funcionarão bem. Reconhecer 
as implicações sobre o desempenho das interações entre as variantes do TCP é uma atividade intricada. 

Em outras palavras, você poderia argumentar que o TCP não é mais definido por uma especificação, mas 
sim por uma implementação. A questão é: por qual implementação? 





Se o resultado for positivo, a origem diminui o tamanho da janela em um oitavo. Se o resultado for 
negativo ou zero, a origem aumenta a janela em um tamanho máximo de pacote. Observe que a janela 
muda durante cada ajuste; ou seja, ela oscila em torno do seu ponto ideal. 
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Outra mudança observada conforme a rede se aproxima do congestionamento é o achatamento da 
taxa de transmissão. Um terceiro esquema tira proveito desse fato. A cada RTT, ele aumenta o tamanho 
da janela em um pacote e compara a vazão alcançada com a vazão de quando a janela era menor pela 
quantia de um pacote. Se a diferença for menor do que metadeda vazão alcançada quando somente um 
pacote estava em trânsito — como acontecia no início da conexão -, o algoritmo diminui a janela em um 
pacote. Esse esquema calcula a vazão dividindo o número de bytes pendentes na rede pelo RTT. 

Um quarto mecanismo, que iremos descrever com mais detalhes, é semelhante ao algoritmo anterior, 
porque examina as mudanças na taxa de vazão ou, mais especificamente, as mudanças na taxa de trans- 
missão. Contudo, ele difere do terceiro algoritmo no modo como calcula a vazão, e em vez de procurar uma 
mudança na inclinação da vazão, ele compara a taxa de vazão medida com uma taxa de vazão esperada. 
O algoritmo, que é chamado TCP Vegas, não é bastante implantado na Internet, mas a estratégia que ele 
utiliza continua a ser estudada. (Veja a seção “Leitura adicional” para obter outras informações.) 

A intuição por trás do algoritmo Vegas pode ser vista no gráfico do TCP padrão, dado na Figura 6.18. 
(Veja a nota em destaque para obter uma explicação sobre o nome TCP Vegas.) O gráfico na parte superior 
da Figura 6.18 mostra a janela de congestionamento da conexão; ele mostra a mesma informação dos 
gráficos dados anteriormente nesta seção. Os gráficos do meio e inferior representam novas informações: 
o gráfico do meio mostra a taxa de transmissão média, medida na origem, e o gráfico inferior mostra 
o tamanho de fila médio, medido no roteador que é o gargalo. Todos os três gráficos são sincronizados 
no tempo. No período entre 4,5 e 6,0 segundos (região sombreada), a janela de congestionamento 
aumenta (gráfico superior). Esperamos que a vazão observada também aumente, mas em vez disso ela 
permanece plana (gráfico do meio). Isso porque a vazão não pode aumentar além da largura de banda 
disponível. Além desse ponto, qualquer aumento no tamanho da janela só resulta em pacotes ocupando 
espaço do buffer no roteador gargalo (gráfico inferior). 
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FIGURA 6.18 Janela de congestionamento versus taxa de vazão observada (os três gráficos são sincronizados). Acima, 
janela de congestionamento; no meio, vazão observada; abaixo, espaço do buffer ocupado no roteador. Linha cinza 
clara=JanelaCongestionamento; círculo sólido =expiração do tempo limite; marcas de hachura= instante em que cada pacote 
é transmitido; barras verticais= momento da transmissão inicial de um pacote que por fim foi retransmitido. 
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Uma metáfora útil que descreve o fenômeno ilustrado na Figura 6.18 é dirigir sobre o gelo. O velo- 
címetro (janela de congestionamento) pode dizer que você está indo a 50 quilômetros por hora, mas, 
olhando pela a janela do carro e vendo as pessoas passando por você a pé (taxa de transmissão medida), 
você sabe que não está passando de 8 quilômetros por hora. Essa energia extra está sendo absorvida 
pelos pneus do carro (buffers do roteador). 

O TCP Vegas usa essa ideia para medir e controlar a quantidade de dados extras que essa conexão 
tem em trânsito, onde os “dados extras” significam dados que a origem não teria transmitido se estivesse 
tentando atingir exatamente a largura de banda disponível na rede. O objetivo do TCP Vegas é manter a 
quantidade “certa” de dados extras na rede. Obviamente, se uma origem estiver enviando muitos dados 
extras, isso causará longos atrasos e possivelmente levará ao congestionamento. Menos obviamente, 
se uma conexão estiver enviando muito poucos dados extras, ela não poderá responder rápido o 
suficiente aos aumentos transientes na largura de banda disponível na rede. As ações de prevenção de 
congestionamento no TCP Vegas são baseadas em mudanças na quantidade estimada de dados extras 
na rede, não apenas nos pacotes descartados. Agora, vamos descrever o algoritmo com detalhes. 

Primeiro, inicialize o valor de RTTBásico de um fluxo qualquer com o RTT de um pacote quando o 
fluxo não está congestionado. Na prática, o TCP Vegas define o valor de RTTBásico para o mínimo de 
todos os tempos de ida e volta medidos; esse normalmente é o RTT do primeiro pacote enviado pela 
conexão, antes que as filas do roteador aumentem devido ao tráfego gerado por esse fluxo. Se assumirmos 
que não estamos sobrecarregando a conexão, então a vazão esperada é dada por: 


TaxaEsperada = JanelaCongestionamento/RTT Básico 


onde JanelaCongestionamento é a janela de congestionamento do TCP que consideramos (para fins 
desta discussão) ser igual ao número de bytes em trânsito. 

Segundo, o TCP Vegas calcula a taxa de transmissão atual, TaxaReal. Isso é feito registrando-se a hora 
da transmissão para um pacote distinto, registrando-se quantos bytes são transmitidos entre o momento 
em que o pacote é enviado e quando sua confirmação é recebida, calculando-se o RTT da amostra para 
o referido pacote quando sua confirmação chega e dividindo-se o número de bytes transmitidos pelo 
RTT da amostra. Esse cálculo é feito uma vez a cada intervalo de ida e volta. 

Terceiro, o TCP Vegas compara a TaxaReal com a TaxaEsperada e ajusta a janela de acordo. Considera- 
mos Dif= TaxaEsperada — TaxaReal. Observe que Dif é positivo ou 0 por definição, pois TaxaReal > TaxaEs- 
perada implica que precisamos mudar RTTBásico para o último RTT de amostra. Também definimos dois 
limiares, œ <ß, correspondendo aproximadamente a ter muito pouco e muitos dados extras na rede, res- 
pectivamente. Quando Dif < a, o TCP Vegas aumenta a janela de congestionamento linearmente durante 
o próximo RTT, e quando Dif > 8, o TCP Vegas diminui a janela de congestionamento linearmente durante 
o próximo RTT. O TCP Vegas mantém a janela de congestionamento inalterada quando a <Dif < B. 

Intuitivamente, podemos ver que quanto mais distante a vazão real estiver da vazão esperada, mais 
congestionamento haverá na rede, o que significa que a taxa de transmissão deverá ser reduzida. O 
limiar 8 dispara essa redução. Por outro lado, quando a taxa de vazão real fica muito próximada vazão 
esperada, a conexão corre o risco de não utilizar a largura de banda disponível. O limiar « dispara 
o aumento da taxa de transmissão. O objetivo geral é ficar entre « e 8 bytes extras na rede. 

A Figura 6.19 representa o algoritmo de prevenção de congestionamento do TCP Vegas. O gráfico 
superior refere-se à janela de congestionamento, mostrando a mesma informação dos outros gráficos 
mostrados no decorrer deste capítulo. O gráfico inferior mostra as taxas de vazão esperada e real que 
controlam como o tamanho da janela de congestionamento é definido. É esse gráfico inferior que ilustra 
melhor o modo como o algoritmo funciona. Alinha cinza clara refere-se ao valor de TaxaEsperada, enquanto 
a linha preta mostra a TaxaReal. A faixa larga sombreada mostra a região entre os limiares « e 8; o topo 
da faixa sombreada está a æ KBps de distância da TaxaEsperada, e a parte inferior da faixa sombreada 
está a 8 KBps de distância da TaxaEsperada. O objetivo é manter a TaxaReal entre esses dois limiares, 
ou seja, dentro da região sombreada. Sempre que a TaxaReal cai abaixo da região sombreada (ou seja, 
fica muito distante da TaxaEsperada), o TCP Vegas diminui a janela de congestionamento, pois teme 
que muitos pacotes estejam sendo mantidos em buffer na rede. De modo semelhante, sempre que a 
TaxaReal fica acima da região sombreada (ou seja, fica muito próxima da TaxaEsperada), o TCP Vegas 
aumenta a janela de congestionamento, pois teme que esteja subutilizando a rede. 
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FIGURA 6.19 Gráfico do mecanismo de prevenção de congestionamento do TCP Vegas. No alto, a janela de congestionamento; abaixo, 
a vazão esperada (linha cinza claro) e real (linha preta). A área sombreada é a região entre os limiares a e £. 


Como o algoritmo, conforme acabamos de apresentar, compara a diferença entre as taxas de vazão 
real e esperada e os limiares a e /3, esses dois limiares são definidos em termos de KBps. Porém, talvez seja 
mais preciso pensar em termos de quantos buffers extras a conexão está ocupando na rede. Por exemplo, 
em uma conexão com um RTTBásico de 100 ms e um tamanho de pacote de 1 KB, se «= 30 KBps e g= 
60 KBps, então podemos pensar em « como especificando que a conexão precisa estar ocupando pelo 
menos três buffers extras na rede e 8 como especificando que a conexão não deverá ocupar mais de seis 
buffers extras na rede. Na prática, um valor de «a como um buffer e 8 como três buffers funciona bem. 

Finalmente, você notará que o TCP Vegas diminui a janela de congestionamento linearmente, aparente- 
mente em conflito com a regra de que a diminuição multiplicativa é necessária para garantir a estabilidade. 
A explicação é que o TCP Vegas usa diminuição multiplicativa quando ocorre umaexpiração do tempo 
limite; a diminuição linear que descrevemos é uma diminuição antecipada na janela de congestionamento 
que, espera-se, acontece antes que ocorra o congestionamento, quando pacotes são descartados. 


AVALIANDO UM NOVO MECANISMO DE CONTROLE DE CONGESTIONAMENTO 


Suponha que você desenvolva um novo mecanismo de controle de congestionamento e queira avaliar 
seu desempenho. Por exemplo, você poderia querer compará-lo com o mecanismo atual sendo usado na 
Internet. Como você consegue medir e avaliar seu mecanismo? Embora houvesse uma época em que o 
principal objetivo da Internet na vida era dar suporte à pesquisa de redes, hoje ela é uma grande rede de 
produção e, portanto, completamente imprópria para executar uma experiência controlada. 

Se a sua técnica é puramente fim afim - ou seja, se ela considera apenas os roteadores FIFO dentro da 
Internet -, então é possível executar seu mecanismo de controle de congestionamento sobre um pequeno 
conjunto de hosts e medir a vazão que suas conexões são capazes de alcançar. Porém, precisamos fazer 
um alerta aqui. É muito fácil inventar um mecanismo de controle de congestionamento que consiga cinco 
vezes a vazão do TCP através da Internet. Você simplesmente joga pacotes na Internet em uma taxa elevada, 
causando congestionamento. Todos os outros hosts executando TCP detectam esse congestionamento e 
reduzem a taxa na qual estão enviando pacotes. Seu mecanismo, então, consome felizmente toda a largura 
de banda. Essa estratégia é rápida, mas não é de forma alguma justa. 

Experimentar diretamente na Internet, mesmo quando feito com cautela, não funcionará quando 
o seu mecanismo de controle de congestionamento envolve mudanças nos roteadores. Simplesmente não 
é prático mudar o software que é executado em milhares de roteadores para avaliar um novo algoritmo de 
controle de congestionamento. Nesse caso, os projetistas de rede são forçados a testar seus sistemas em redes 
simuladas ou em redes de testes privadas. Por exemplo, os gráficos de TCP apresentados neste capítulo foram 
gerados por uma implementação do TCP que estava funcionando em um simulador de rede. O desafio em 
uma simulação ou em uma rede de testes é conseguir uma topologia e uma carga de trabalho de tráfego que 
consiga representar a Internet real. 
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6.5 Qualidade de serviço 


Durante muitos anos, as redes por comutação de pacotes ofereceram a promessa de dar suporte a 
aplicações de multimídia, ou seja, aquelas que combinam áudio, vídeo e dados. Afinal, uma vez digi- 
talizadas, as informações de áudio e vídeo tornam-se como qualquer outra forma de dados — um fluxo 
de bits a serem transmitidos. Um obstáculo para a realização dessa promessa tem sido a necessidade 
de enlaces com maior largura de banda. Recentemente, porém, melhorias na codificação reduziram 
as necessidades de largura de banda das aplicações de áudio e vídeo, enquanto ao mesmo tempo as 
velocidades de enlace aumentaram. 

Todavia, há mais coisas envolvidas na transmissão de áudio e vídeo por uma rede do que apenas ofe- 
recer largura de banda suficiente. Os participantes de uma conversa por telefone, por exemplo, esperam 
poder conversar de modo que uma pessoa seja capaz de responder a algo dito pela outra e de ser ouvida 
quase que imediatamente. Assim, a prontidão da entrega pode ser muito importante. Referimo-nos a 
aplicações que são sensíveis à prontidão dos dados como aplicações de tempo real. Aplicações de voz e 
vídeo costumam ser exemplos canônicos, mas existem outras, como controle industrial - você gostaria 
que um comando enviado a um braço de robô chegasse até ele antes que o braço batesse em alguma 
coisa. Até mesmo aplicações de transferência de arquivos podem ter restrições de prontidão, como um 
requisito de que uma atualização de banco de dados seja completada à noite, antes que a empresa que 
precisa dos dados seja aberta no dia seguinte. 

As características distintas das aplicações de tempo real é que elas precisam de algum tipo de garantia 
da rede de que os dados provavelmente chegarão a tempo (para alguma definição de “a tempo”). Embora 
uma aplicaçãoque não seja de tempo real possa usar uma estratégia de retransmissão fim a fim para 
certificar-se de que os dados chegarão corretamente, tal estratégia não é capaz de oferecer prontidão. 
Se os dados chegarem tarde, a retransmissão só aumentará a latência total. A chegada a tempo precisa 
ser fornecida pela própria rede (os roteadores), e não apenas nas bordas da rede (os hosts). Portanto, 
concluímos que o modelo de melhor esforço, em que a rede tenta entregar seus dados mas não faz 
promessas e deixa a operação de recuperação da perda para as bordas, não é suficiente para aplicações 
de tempo real. O que precisamos é de um novo modelo de serviço, em que as aplicações que precisam 
de garantias maiores possam pedi-las à rede. A rede pode responder, então, oferecendo uma garantia 
de que fará melhor, ou talvez dizendo que não pode prometer algo melhor no momento. Observe que 
tal modelo de serviço é um superconjunto do modelo atual: as aplicações que estão satisfeitas com o 
serviço de melhor esforço devem ser capazes de usar o novo modelo de serviço; seus requisitos sim- 
plesmente são menos rigorosos. Isso significa que a rede tratará alguns pacotes de forma diferente dos 
outros — algo que não é feito no modelo de melhor esforço. Normalmente, diz-se que uma rede que 
possa oferecer esses diferentes níveis de serviço é uma rede com suporte a qualidade de serviço (QoS 
— Quality of Service). 

Neste ponto, você poderia estar pensando “Espere aí. A Internet já não admite aplicações de tempo 
real?” Neste ponto, a maioria de nós já experimentou algum tipo de aplicação de telefonia na Internet, 
como o Skype, e elas parecem funcionar bem. O motivo para isso, em parte, é que o serviço de melhor 
esforço frequentemente é muito bom. (O Skype em particular também faz uma série de coisas in- 
teligentes para tentar lidar com a falta de QoS na Internet.) A palavra-chave aqui é “frequentemente”. 
Se você quiser um serviço que seja confiavelmente bom para suas aplicações de tempo real, então o 
melhor esforço — que, por definição, não oferece garantias — não será suficiente. Mais adiante, vamos 
retornar ao assunto de o quanto a QoS realmente é necessária. 


6.5.1 Requisitos da aplicação 


Antes de examinarmos os diferentes protocolos e mecanismos que podem ser usadospara oferecer 
qualidade de serviço às aplicações, devemos tentar entender quais são as necessidades dessas aplicações. 
Para começar, podemos dividir as aplicações em dois tipos: tempo real e tempo não real. A última classe 
às vezes é chamada aplicações de dados tradicionais, pois tradicionalmente têm sido as principais apli- 
cações encontradas nas redes de dados. Elas incluem a maioria das aplicações populares, como Telnet, 
FTP correio eletrônico, navegação na Web e assim por diante. Todas essas aplicações podem trabalhar 
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sem garantias de tempo referentes à entrega de dados. Outro termo para essa classe de aplicações de 
tempo não real é aplicações elásticas, pois ela são capazes de se adaptar muito bem se houver maiores 
atrasos. Observe que essas aplicações podem se beneficiar de atrasos de menor duração, mas não se 
tornam inutilizáveis quando os atrasos aumentam. Observe também que seus requisitos de atraso variam 
desde aplicações interativas, como Telnet, até outras mais assíncronas, como o correio eletrônico, com 
as transferências interativas em massa, como o FTP sendo um meio termo entre elas. 


Exemplo de áudio em tempo real 

Como um exemplo concreto de uma aplicação de tempo real, considere uma aplicação de áudio, seme- 
lhante à que ilustramos na Figura 6.20. Os dados são gerados pela coleta de amostras em um microfone 
e sua digitalização usando um conversor analógico-digital (AD). As amostras digitais são colocadas 
em pacotes, que são transmitidos pela rede e recebidos na outra extremidade. No host receptor, os 
dados precisam ser reproduzidos em alguma taxa apropriada. Por exemplo, se as amostras de voz fossem 
coletadas em uma taxa de uma a cada 125 us, elas seriam reproduzidas na mesma taxa. Assim, podemos 
pensar em cada amostra como tendo um tempo de reprodução específico: o ponto no tempo em que 
ela precisa estar no host receptor. No exemplo de voz, cada amostra possui um tempo de reprodução 
que é 125 us depois da amostra anterior. Se os dados chegarem depois do seu tempo de reprodução 
apropriado, seja porque foram atrasados na rede ou porque foram descartados e retransmitidos mais 
tarde, eles são basicamente inúteis. É essa inutilidade completa dos dados atrasados que caracteriza as 
aplicações de tempo real. Nas aplicações elásticas, seria bom se os dados aparecessem a tempo, mas 
ainda podemos usá-los quando isso não acontece. 

Uma forma de fazer com que nossa aplicação de voz funcione seria certificar-se de que todas as 
amostras levam exatamente o mesmo tempo para atravessar a rede. Assim, como as amostras são 
injetadas em uma taxa de uma por 125 us, elas aparecerão no receptor na mesma taxa, prontas para 
serem reproduzidas. Contudo, geralmente é difícil garantir que todos os dados atravessando uma rede 
de comutação de pacotes experimentam exatamente o mesmo atraso. Os pacotes encontram filas em 
switches ou roteadores e os tamanhos dessas filas variam com o tempo, significando que os atrasos 
costumam variar com o tempo e, por conseguinte, são potencialmente diferentes para cada pacote 
no fluxo de áudio. A maneira de lidar com isso no sistema final receptor é colocar em buffer alguma 
quantidade de dados em reserva, fornecendo assim sempre uma reserva de pacotes aguardando para 
serem reproduzidos na hora certa. Se um pacote for atrasado por pouco tempo, ele irá para o buffer até 
que chegue seu momento de reprodução. Se ele for atrasado por muito tempo, então não precisará ser 
armazenado por muito tempo no buffer do receptor antes de ser reproduzido. Assim, acrescentamos 
efetivamente um deslocamento constante ao tempo de reprodução de todos os pacotes, como uma 
forma de garantia. Chamamos esse deslocamento de ponto de reprodução. A única ocasião em que temos 
problema é se os pacotes forem atrasados na rede por tanto tempo que cheguem após seu momento 
de reprodução, causando o esvaziamento do buffer de reprodução. 

A operação de um buffer de reprodução é ilustrada na Figura 6.21. A linha diagonal da esquerda 
mostra os pacotes sendo gerados em uma taxa constante. A linha ondulada mostra quando os pacotes 
chegam, alguma quantidade de tempo variável depois que foram enviados, dependendo do que encon- 
traram na rede. A linha diagonal da direita mostra os pacotes sendo reproduzidos em uma taxa constante, 
depois de permanecerem no buffer de reprodução por algum período de tempo. Contanto que a linha 
de reprodução esteja afastada à direita por um tempo suficiente, a variação no atraso da rede nunca 
é observada pela aplicação. Contudo, se movermos a linha de reprodução um pouco para a esquerda, 
então alguns pacotes começarão a chegar muito tarde para serem úteis. 
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FIGURA 6.20 Uma aplicação de áudio. 
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FIGURA 6.21 Um buffer de reprodução. 
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FIGURA 6.22 Exemplo de distribuição dos atrasos para uma conexão da Internet. 


Para a nossa aplicação de áudio, existem limites para o tempo que podemos esperar pela reprodução dos 
dados. É difícil conduzir uma conversa se o intervalo entre quando você fala e quando seu ouvinte escuta 
é maior do que 300 ms. Assim, o que queremos da rede, nesse caso, é uma garantia de que todos os nossos 
dados chegarão dentro de 300 ms. Se os dados chegarem antes disso, eles ficarão no buffer até o momento 
certo da reprodução. Se chegarem depois, não temos utilidade para eles e precisamos descartá-los. 

Para apreciar melhor como o atraso da rede pode ser variável, a Figura 6.22 mostra o atraso unidi- 
recional medido por certo caminho através da Internet no decorrer de um dia específico. Embora os 
números exatos variem, dependendo do caminho e da data, o fator principal aqui é a variabilidade 
do atraso, que é coerentemente encontrada em quase todo caminho a qualquer momento. Conforme 
indicado pelas porcentagens acumuladas dadas no alto do gráfico, 97% dos pacotes nesse caso tiveram 
uma latência de 100 ms ou menos. Isso significa que, se nossa aplicação de áudio do exemplo definisse 
o ponto de reprodução em 100 ms, então, na média, 3 de cada 100 pacotes chegariam muito tarde para 
serem utilizados. Uma coisa importante a observar sobre esse gráfico é que a cauda da curva — o quanto 
ela se estende à direita — é muito longa. Teríamos que definir o ponto de reprodução em mais de 200 ms 
para garantir que todos os pacotes chegariam a tempo. 


Taxonomia das aplicações de tempo real 

Agora que temos uma ideia concreta de como funcionam as aplicações de tempo real, podemos 
examinar algumas classes de aplicações diferentes, que servem para motivar nosso modelo de serviço. 
A taxonomia a seguir deve muito ao trabalho de Clark, Braden, Shenker e Zhang, cujos artigos sobre 
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FIGURA 6.23 Taxonomia das aplicações. 


esse assunto podem ser encontrados na seção de “Leitura adicional” deste capítulo. A taxonomia das 
aplicações é resumida na Figura 6.23. 

A primeira característica pela qual podemos categorizar as aplicações de tempo real é sua tolerância à 
perda de dados, onde “perda” pode ocorrer porque um pacote chegou muito tarde para ser reproduzido, 
ou então devido a causas normais na rede. Por um lado, uma amostra de áudio perdida pode ser in- 
terpolada a partir das amostras adjacentes com relativamente pouco efeito sobre a qualidade de áudio 
percebida. Apenas quando mais e mais amostras são perdidas é que a qualidade cai a ponto de que a 
fala se torne incompreensível. Por outro lado, um programa de controle de robô provavelmente é um 
exemplo de uma aplicação de tempo real que não pode tolerar perdas — perder um pacote que contém 
o comando instruindo o braço do robô a parar é inaceitável. Assim, podemos classificar as aplicações de 
tempo real como tolerantes ou intolerantes, dependendo se elas podem ou não tolerar a perda ocasional. 
(Como uma observação, perceba que muitas aplicações de tempo real são mais tolerantes a perdas 
ocasionais do que aplicações de tempo não real. Por exemplo, compare nossa aplicação de áudio com 
o FTP no qual a perda não corrigida de um bit poderia tornar um arquivo completamente inútil.) 

Uma segunda maneira de caracterizar as aplicações de tempo real é por sua adaptabilidade. Por 
exemplo, uma aplicação de áudio poderia ser capaz de adaptar-se à quantidade de atraso que os 
pacotes experimentam enquanto atravessam a rede. Se observarmos que os pacotes estão quase sem- 
pre chegando dentro de 300 ms após o envio, então podemos definir nosso ponto de reprodução de 
acordo, colocando em buffer quaisquer pacotes que cheguem com menos de 300 ms. Suponha que mais 
tarde observemos que todos os pacotes estão chegando dentro de 100 ms após o envio. Se adiantarmos 
nosso ponto de reprodução para 100 ms, então os usuários da aplicação provavelmente perceberiam 
uma melhoria. O processo de deslocar o ponto de reprodução, na realidade, exigiriaa reproduçãodas 
amostras em uma taxa mais alta por algum período de tempo. Com uma aplicação de voz, isso pode ser 
feito de um modo quase imperceptível, simplesmente encurtando os silêncios entre as palavras. Assim, 
o ajuste do ponto de reprodução é muito fácil nesse caso, e foi efetivamente implementadoem várias 
aplicações de voz, como no programa de teleconferência com áudio conhecido como vat. Observe que 
o ajuste do ponto de reprodução pode acontecer em qualquer direção, mas na realidade isso envolve 
distorcer o sinal reproduzido durante o período de ajuste, e que os efeitos dessa distorção dependerão 
muito de como o usuário final utiliza os dados. 

Observe que, se definirmos nosso ponto de reprodução com base na suposição de que todos os 
pacotes chegarão dentro de 100 ms e depois descobrirmos que alguns pacotes estão chegando ligeira- 
mente atrasados, teremos que descartá-los, enquanto não teríamos que fazer isso se tivéssemos deixado 
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o ponto de reprodução em 300 ms. Assim, devemos avançar o ponto de reprodução somente quando 
ele oferece uma vantagem perceptível e somente quando tivermos alguma evidência de que o número 
de pacotes atrasados será aceitavelmente pequeno. Podemos fazer isso em razão do histórico recente 
observado ou devido a alguma garantia da rede. 

Chamamos as aplicações que podem ajustar seu ponto de reprodução de aplicações adaptáveis ao 
atraso. Outra classe de aplicações adaptáveis são as aplicações adaptáveis à taxa. Por exemplo, muitos 
algoritmos de codificação de vídeo podem escolher entre seus requisitos de taxa de bits e qualidade. 
Assim, se descobrirmos que a rede é capaz de suportar certa largura de banda, podemos definir nossos 
parâmetros de codificação de acordo. Se mais largura de banda tornar-se disponível mais tarde, podemos 
mudar os parâmetros para aumentar a qualidade. 


Técnicas para o suporte a QoS 

Considerando esse rico espaço de requisitos da aplicação, o que precisamos é de um modelo de serviço 
mais rico, que atenda às necessidades de qualquer aplicação. Isso nos leva a um modelo de serviço com 
não apenas uma classe (melhor esforço), mas com várias classes, cada uma disponibilizada para atender 
às necessidades de algum conjunto de aplicações. Para esse fim, agora estamos prontos para examinar 
algumas das técnicas que foram desenvolvidas para oferecer uma grande variedade de qualidades de 
serviço. Estas podem ser divididas em duas categorias gerais: 


e Técnicas de alta granularidade, que oferecem Qos a aplicações ou fluxos individuais. 
e Técnicas de baixa granularidade, que oferecem Qos a grandes classes de dados ou tráfego 
agregado. 


Na primeira categoria, encontramos os Serviços Integrados (Integrated Services), uma arquitetura 
de QoS desenvolvida na IETF e normalmente associada com o RSVP (Resource Reservation Protocol — 
protocolo de reserva de recursos). Na segunda categoria estão os Serviços Diferenciados (Differentiated 
Services), que provavelmente é o mecanismo de QoS mais empregado no momento em que escrevíamos 
este livro. Discutimos cada uma deles nas próximas duas subseções. 

Finalmente, conforme sugerimos no início desta seção, adicionar suporte a QoS na rede não é 
necessariamente tudo que é necessário para dar suporte a aplicações de tempo real. Concluímos nossa 
discussão revisando o que o host final poderia fazer para dar melhor suporte aos fluxos de tempo real, 
independente dos amplamente utilizados mecanismos de QoS, como Serviços Integrados e Serviços 
Diferenciados. 


6.5.2 Serviços Integrados (RSVP) A 


RSVP 
O termo Serviços Integrados (Integrated Services, normalmente chamado IntServ, para abreviar) refere-se 
a um conjunto de trabalhos que foi produzido pela IETF por volta de 1995-97. O grupo de trabalho IntServ 
desenvolveu especificações de uma série de classes de serviço, projetadas para atender às necessidades 
de alguns dos tipos de aplicações descritos anteriormente. Ele também definiu como o RSVP poderia 
ser usado para fazer reservas usando essas classes de serviço. Os parágrafos a seguir contêm uma visão 
geral dessas especificações e dos mecanismos que são usados para implementá-las. 


Classes de serviço 
Uma das classes de serviço é voltada para aplicações intolerantes. Essas aplicações exigem que um pacote 
nunca chegue atrasado. A rede precisa garantir que o atraso máximo que qualquer pacote experimentará 
possui algum valor especificado; a aplicação pode, então, definir seu ponto de reprodução de modo que 
nenhum pacote chegue depois do seu tempo de reprodução. Consideramos que a chegada adiantada de 
pacotes sempre pode ser tratada pelo uso de buffer. Esse serviço é conhecido como serviço garantido. 
Além do serviço garantido, a IETF considerou vários outros serviços, mas, por fim, escolheu um 
para atender às necessidades das aplicações tolerantes e adaptáveis. O serviço é conhecido como carga 
controlada e foi motivado pela observação de que as aplicações existentes desse tipo executam muito 
bem em redes que não são muito carregadas. A aplicação de áudio vat, por exemplo, ajusta seu ponto 
de reprodução à medida que o atraso da rede varia, e produz qualidade de áudio razoável enquanto as 
perdas permanecerem da ordem de 10% ou menos. 
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O objetivo do serviço de carga controlada é simular uma rede pouco carregada para aquelas aplicações 
que solicitam este tipo serviço, embora a rede como um todo possa na realidade estar bastante carregada. 
O truque para isso é usar um mecanismo de enfileiramento, como o WFQ (ver Seção 6.2), para isolar o 
tráfego de carga controlada do restante do tráfego e prover alguma forma de controle de admissão para 
limitar a quantidade total de tráfego de carga controlada em um enlace, de modo que a carga seja mantida 
razoavelmente baixa. Discutimos sobre o controle de admissão com mais detalhes a seguir. 

Naturalmente, essas duas classes de serviço são um subconjunto de todas as classes que poderiam 
ser fornecidas. De fato, outros serviços foram especificados, mas nunca padronizados como parte 
do trabalho da IETF Até aqui, os dois serviços descritos anteriormente (juntamente com o melhor 
esforço tradicional) se mostraram adequados para atender às necessidades de uma grande variedade 
de aplicações. 


Visão geral dos mecanismos 

Agora que expandimos nosso modelo de serviço de melhor esforço com algumas novas classes de 
serviço, a próxima pergunta é como implementar uma rede que ofereça esses serviços às aplicações. 
Esta seção esboça os principais mecanismos. Lembre-se, enquanto estiver lendo esta seção, que os 
mecanismos sendo descritos ainda estão sendo preparados pela comunidade de projeto da Internet. A 
coisa principal que deve ser retirada da discussão é um conhecimento geral das partes envolvidas no 
suporte ao modelo de serviço esboçado anteriormente. 

Primeiro, enquanto com um serviço de melhor esforço podemos simplesmente dizer à rede por onde 
queremos que nossos pacotes entrem e saiam dela, um serviço de tempo real envolve dizer à rede algo 
mais a respeito do tipo de serviço que exigimos. Podemos lhe dar informações qualitativas como “use 
um serviço de carga controlada” ou informações quantitativas como “preciso de um atraso máximo de 
100 ms”. Além de descrever o que queremos, precisamos dizer à rede algo sobre o que vamos injetar 
nela, pois uma aplicação de pouca largura de banda irá exigir menos recursos de rede do que uma 
aplicação de alta largura de banda. O conjunto de informações que oferecemos à rede é conhecido 
como especificação de fluxo. Esse nome vem da ideia de que um conjunto de pacotes associados a uma 
única aplicação e que compartilham requisitos comuns é chamado fluxo, coerente com nosso uso do 
termo “fluxo” na Seção 6.1. 

Segundo, quando pedimos à rede para nos oferecer determinado serviço, a rede precisa decidir se 
pode realmente oferecer esse serviço. Por exemplo, se dez usuários pedirem um serviço em que cada 
um coerentemente use 2 Mbps de capacidade de enlace, e todos eles compartilhem um enlace com 
capacidade de 10 Mbps, a rede terá que dizer não a alguns deles. O processo de decidir quando dizer 
não é chamado controle de admissão. 

Terceiro, precisamos de um mecanismo pelo qual os usuários da rede e os componentes da própria 
rede trocam informações como solicitações de serviço, especificações de fluxo e decisões de controle de 
admissão. Geralmente, isso é chamado sinalização, mas, como essa palavra possui vários significados, 
vamos nos referir a esse processo como reserva de recursos, a qual é obtida por meio de um protocolo 
de reserva de recursos. 

Finalmente, quando os fluxos e seus requisitos tiverem sido descritos e as decisões de controle de 
admissão tiverem sido tomadas, os switches e roteadores da rede precisam atender aos requisitos dos 
fluxos. Uma parte importante para atender a esses requisitos é gerenciar o modo como os pacotes são 
enfileirados e escalonados para transmissão nos switches e roteadores. Esse último mecanismo é o 
escalonamento de pacotes. 


Especificações de fluxo 

Existem duas partes independentes na especificação de fluxo: a parte que descreve as características de 
tráfego do fluxo (chamada TSpec) e a parte que descreve o serviço solicitado da rede (RSpec). A RSpec 
é bastante específica ao serviço e relativamente fácil de descrever. Por exemplo, com um serviço de 
carga controlada, a RSpec é trivial: a aplicação apenas solicita serviço de carga controlada sem qualquer 
parâmetro adicional. Com um serviço garantido, você poderia especificar um atraso alvo ou limite. (Na 
especificação de serviço garantido da IETF você especifica não um atraso, mas outra quantidade a partir 
da qual o atraso pode ser calculado.) 
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ATSpec é um pouco mais complicada. Como mostramos no nosso exemplo anterior, precisamos dar 
à rede informações suficientes sobre a largura de banda utilizada pelo fluxo para permitir que sejam 
tomadas decisões inteligentes de controle de admissão. Porém, para a maioria das aplicações, a largura 
de banda não é um único número; ela é algo que varia constantemente. Uma aplicação de vídeo, por 
exemplo, geralmente gerará mais bits por segundo quando a cena está mudando rapidamente do que 
quando está parada. Apenas conhecer a largura de banda média a longo prazo não é suficiente, como 
ilustra o exemplo a seguir. Suponha que tenhamos dez fluxos que chegam a um switch em portas de en- 
trada separadas e que saem pelo mesmo enlace de 10 Mbps. Considere que, ao longo de algum intervalo 
de tempo adequadamente longo, cada fluxo não possa enviar mais do que 1 Mbps. Você poderia pensar 
que isso não apresenta problema. Porém, se essas são aplicações de taxa de bit variável, comovídeo 
compactado, então elas ocasionalmente transmitirão a uma taxa superior às suas taxas médias. Se fontes 
suficientes enviarem dados acima de suas taxas médias, então a taxa total em que os dados chegam ao 
switch será maior do que 10 Mbps. Esses dados em excesso serão enfileirados antes que possam ser 
enviados ao enlace. Quanto maior o intervalo em que essa condição persiste, maior o tamanho que a 
fila atinge. Os pacotes poderiam ter que ser descartados, e mesmo que não se chegue a tanto, os dados 
que ficam na fila estão sendo atrasados. Se os pacotes forem atrasados por um tempo suficientemente 
longo, o serviço que foi solicitado não será fornecido. 

O modo exato como gerenciamos nossas filas para controlar o atraso e evitar o descarte de pacotes 
é algo que discutiremos a seguir. Contudo, observe aqui que precisamos saber algo a respeito de como 
a largura de banda de nossas origens varia com o tempo. Um modo de descrever as características de 
largura de banda das origens se chama filtro de balde de fichas (“token bucket”). Esse tipo de filtro é 
descrito por dois parâmetros: uma taxa de fichas t e uma profundidade de balde B. Ele funciona da 
seguinte maneira. Para poder enviar um byte, preciso ter uma ficha (token). Para enviar um pacote de 
tamanho n, preciso de n fichas. Eu começo sem fichas e os acumulo a uma taxa de t por segundo. Não 
posso acumular mais do que B fichas. Isso significa que eu posso enviar uma rajada de até B bytes para 
a rede, com a velocidade que eu quiser, mas ao longo de um intervalo suficientemente longo, não posso 
enviar mais do que t bytes por segundo. Acontece que essa informação é muito útil para o algoritmo de 
controle de admissão, quando ele tenta descobrir se pode acomodar uma nova solicitação de serviço. 

A Figura 6.24 ilustra como um balde de fichas pode ser usado para caracterizar os requisitos de 
largura de banda de um fluxo. Para simplificar, considere que cada fluxo pode enviar dados como bytes 
individuais, ao invés de pacotes. O fluxo A gera dados a uma taxa constante de 1 MBps, de modo que 
ele pode ser descrito por um filtro de balde de fichas com uma taxa t = 1 MBps e uma profundidade de 
balde de 1 byte. Isso significa que ele recebe fichas a uma taxa de 1 MBps, mas não pode armazenar mais 
do que 1 ficha — ele as gasta imediatamente. O fluxo B também transmite a uma taxa média de 1 MBps 
a longo prazo, mas faz isso transmitindo a 0,5 MBps por 2 segundos e depois a 2 MBps por 1 segundo. 
Como a taxa do balde de fichas t é, de certa forma, uma taxa média de longo prazo, o fluxo B pode ser 
descrito por um balde de fichas com uma taxa de 1 MBps. Porém, ao contrário do fluxo A, o fluxo B 
precisa de uma profundidade de balde B de pelo menos 1 MB, de modo que possa armazenar as fichas 
enquanto envia a menos de 1 MBps para serem usadas quando enviar a 2 MBps. Para os 2 primeiros 
segundos neste exemplo, ele recebe fichas a uma taxa de 1 MBps, mas as gasta a uma taxa de apenas 0,5 
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MBps, de modo que ele economiza 2 x 0,5=1 MB de fichas, que são então gastas no terceiro segundo 
(junto com as novas fichas que continuam a se acumular nesse segundo) para enviar dados a 2 MBps. 
Ao final do terceiro segundo, tendo gasto as fichas em excesso, ele começa a armazená-las novamente, 
enviando a 0,5 MBps mais uma vez. 

É interessante observar que um único fluxo pode ser descrito por muitos baldes de fichas diferentes. 
Como um exemplo trivial, o fluxo A poderia ser descrito pelo mesmo balde de fichas do fluxo B, com uma 
taxa de 1 MBps e uma profundidade de balde de 1 MB. O fato de nunca realmente precisar acumular 
fichas não torna essa uma descrição pouco precisa, mas significa que deixamos de transmitir alguma 
informação útil à rede — o fato de que o fluxo A é na realidade muito consistente em suas necessidades 
de largura de banda. Em geral, é bom ser o mais explícito possível a respeito das necessidades de largura 
de banda de uma aplicação, para evitar alocação demasiada de recursos na rede. 


Controle de admissão 

Aideia por trás do controle de admissão é simples: quando algum novo fluxo deseja receber determinado 
nível de serviço, o controle de admissão examina a TSpec e a RSpec do fluxo e tenta decidir se o serviço 
desejado pode ser fornecido a essa quantidade de tráfego, dados os recursos atualmente disponíveis, 
sem fazer com que qualquer fluxo previamente admitido receba pior serviço do que havia solicitado. 
Se ele puder oferecer esse serviço, o fluxo será admitido; se não, então ele será recusado. A parte difícil 
é descobrir quando dizer sim e quando dizer não. 

O controle de admissão depende muito do tipo de serviço solicitado e da estratégia de enfileiramento 
empregada nos roteadores; discutimos esse último tópico mais adiante nesta seção. Para um serviço 
garantido, você precisa ter um bom algoritmo para tomar uma decisão sim/não definitiva. A decisão 
é bastante simples se o enfileiramento justo ponderado, discutido na Seção 6.2, for usado em cada 
roteador. Para um serviço de carga controlada, a decisão pode ser baseada na heurística, como “na última 
vez em que permiti que um fluxo com essa TSpec entrasse nessa classe, os atrasos na classe excederam 
o limite aceitável, e por isso é melhor dizer não”, ou “meus atrasos atuais estão tão limites que eu devo 
ser capaz de admitir outro fluxo sem dificuldade”. 

O controle de admissão não deve ser confundido com policiamento. O primeiro é uma decisão para 
cada fluxo referindo-se à admissão ou à recusa de um novo fluxo. O segundo é uma função aplicada com 
base em cada pacote, para certificar-se de que um fluxo esteja de acordo com a TSpec que foi usada para 
fazer a reserva. Se um fluxo não estiver de acordo com sua TSpec — por exemplo, porque está enviando 
o dobro de bytes por segundo do que ele disse que faria —, então ele provavelmente interferirá com o 
serviço fornecido a outros fluxos, e alguma ação corretiva precisará ser tomada. Existem várias opções, 
sendo a mais óbvia descartar os pacotes problemáticos. Porém, outra opção seria verificar se os pacotes 
realmente estão interferindo com o serviço de outros fluxos. Se não estiverem interferindo, os pacotes 
poderiam ser enviados depois de serem marcados com um rótulo que diz, com efeito: “Este pacote não 
está em conformidade. Descarte-o primeiro se precisar descartar alguns pacotes.” 

O controle de admissão está bastante relacionado à questão importante da política. Por exemplo, 
um administrador de rede poderia permitir que as reservas feitas pelo presidente de sua empresa sejam 
admitidas, enquanto rejeita as reservas feitas pelos funcionários de cargos mais baixos. Naturalmente, 
a solicitação de reserva do presidente ainda poderia falhar se os recursos solicitados não estivessem 
disponíveis, e por isso vemos que as questões de política e disponibilidade de recursos podem ser 
resolvidas quando são tomadas decisões de controle de admissão. A aplicação de política à rede é uma 
área que estava recebendo muita atenção no momento em que escrevíamos este livro. 


Protocolo de reserva 

Embora as redes orientadas a conexão sempre tenham precisado de algum tipo de protocolo de configu- 
ração para estabelecer o estado de circuito virtual necessário nos switches, as redes sem conexão, como 
a Internet, não tiveram tais protocolos. Porém, como esta seção indicou, precisamos oferecer muito 
mais informações à nossa rede quando quisermos obter dela um serviço de tempo real. Embora tenha 
havido muitos protocolos de configuração propostos para a Internet, aquele em que está concentrada 
a maior atenção atualmente é chamado Resource Reservation Protocol (RSVP). Ele é particularmente 
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interessante porque difere substancialmente dos protocolos de sinalização convencionais para as redes 
orientadas a conexão. 

Uma das principais suposições por trás do RSVP é que ele não deve prejudicar a robustez que encon- 
tramos nas redes atuais sem conexão. Como as redes sem conexão contam com pouco ou nenhum 
estado sendo armazenado na própria rede, é possível que os roteadores falhem e sejam reinicializados 
e que os enlaces sejam ativados e desativados enquanto a conectividade fim a fim é mantida. O RSVP 
tenta manter essa robustez usando a ideia de estado soft nos roteadores. O estado soft — ao contrário 
do estado hard, encontrado nas redes orientadas a conexão — não precisa ser excluído explicitamente 
quando não for mais necessário. Em vez disso, ele esgota seu tempo limite depois de algum período de 
tempo razoavelmente curto (digamos, um minuto), se não for atualizado periodicamente. Mais adiante, 
veremos como isso ajuda na robustez. 

Outra característica importante do RSVP é que ele tem como objetivo dar suporte a fluxos de multicast 
com a mesma eficiência dos fluxos de unicast. Isso não é surpresa, pois muitas das primeiras aplicações 
que poderiam se beneficiar da melhor qualidade de serviço também eram aplicações multicast — vat e vic, 
por exemplo. Uma das observações dos projetistas do RSVP é que a maioria das aplicações de multicast 
possui muito mais receptores do que emissores, conforme representado pela grande audiência e um 
palestrante para uma palestra. Além disso, os receptores podem ter requisitos diferentes. Por exemplo, 
um receptor poderia querer receber dados de apenas um emissor, enquanto outros poderiam querer 
receber dados de todos os emissores. Em vez de fazer com que os emissores mantenham o registro de 
um número potencialmente grande de receptores, faz mais sentido deixar que os receptores mantenham 
o registro suas próprias necessidades. Isso sugere a técnica orientada a receptor, adotada pelo RSVP. Em 
comparação, as redes orientadas a conexão normalmente deixam a reserva de recursos para o emissor, 
assim como normalmente é a origem de uma chamada telefônica que faz com que os recursos sejam 
alocados na rede telefônica. 

O estado soft e a natureza orientada a receptor do RSVP lhe dão uma série de propriedades interes- 
santes. Uma dessas propriedades é que é muito simples aumentar ou diminuir o nível de alocação de 
recursos oferecido a um receptor. Como cada receptor envia periodicamente mensagens de atualização 
para manter o estado soft ativo, é fácil enviar uma nova reserva que solicite um novo nível de recursos. 
Além disso, o estado soft lida corretamente com a possibilidade de falhas da rede ou do nó. No evento 
de uma falha no host, os recursos alocados por esse host a um fluxo naturalmente esgotarão seu tempo 
limite e serão liberados. Para ver o que acontece no caso de uma falha de roteador ou enlace, precisamos 
examinar um pouco mais de perto a mecânica por trás de fazer uma reserva. 

Inicialmente, considere o caso de um emissor e um receptor tentando fazer com que uma reserva para 
o tráfego fluindo entre eles. Existem duas coisas que precisam acontecer antes que um receptor possa 
fazer a reserva. Primeiro, o receptor precisa saber que tráfego o emissor provavelmente enviará, para que 
possa fazer uma reserva apropriada. Ou seja, ele precisa saber a TSpec do emissor. Segundo, ele precisa 
saber que caminho os pacotes seguirão do emissor ao receptor, para que possa estabelecer uma reserva 
de recursos em cada roteador no caminho. Esses dois requisitos podem ser atendidos pelo envio de uma 
mensagem do emissor ao receptor, contendo a TSpec. Obviamente, isso leva a TSpec ao receptor. A outra 
coisa que acontece é que cada roteador examina essa mensagem (chamada mensagem PATH) assim que 
ela passa por ele e descobre o caminho reverso que será usado para enviar reservas do receptor de volta 
ao emissor, em um esforço para levar a reserva a cada roteador no caminho. A construção da árvore de 
multicast em primeiro lugar é feita por mecanismos como aqueles descritos na Seção 4.2. 

Tendo recebido uma mensagem PATH, o receptor envia uma reserva de volta “para cima” na árvore de 
multicast, em uma mensagem RESV. Essa mensagem contém a TSpec do emissor e uma RSpec descrevendo 
os requisitos do receptor. Cada roteador no caminho examina a solicitação de reserva e tenta alocar os re- 
cursos necessários para satisfazê-la. Se a reserva puder ser feita, a solicitação RESV é passada para o próximo 
roteador. Se não, uma mensagem de erro é retornada ao receptor que fez a solicitação. Se tudo correr bem, a 
reserva correta é instalada em cada roteador entre o emissor e o receptor. Enquanto o receptor quiser manter 
a reserva, ele envia a mesma mensagem RESV aproximadamente uma vez a cada 30 segundos. 

Agora, podemos ver o que acontece quando um roteador ou enlace falha. Os protocolos de rotea- 
mento se adaptarão à falha e criarão um novo caminho do emissor ao receptor. As mensagens PATH 
são enviadas aproximadamente a cada 30 segundos e podem ser enviadas mais cedo se um roteador 
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FIGURA 6.25 Fazendo reservas em uma árvore de multicast. 


detectar uma mudança em sua tabela de encaminhamento, de modo que a primeira mensagem após a 
nova rota se estabilizar alcançará o receptor pelo novo caminho. A próxima mensagem RESV do receptor 
seguirá o novo caminho e (espera-se) estabelecerá uma nova reserva no novo caminho. Enquanto isso, 
os roteadores que não estão mais no caminho deixarão de receber mensagens RESV, e essas reservas 
esgotarão seu tempo limite e serão liberadas. Assim, o RSVP lida muito bem com as mudanças na 
topologia, desde que as mudanças de roteamento não sejam excessivamente frequentes. 

A próxima coisa que precisamos considerar é como lidar com o multicast, no qual pode haver vários 
emissores para um grupo e vários receptores. Essa situação é ilustrada na Figura 6.25. Primeiro, vamos 
lidar com vários receptores para um único emissor. Enquanto uma mensagem RESV atravessa a árvore de 
multicast, ela provavelmente alcança uma parte da árvore onde a reserva de algum outro receptor já foi 
estabelecida. Pode ser que os recursos reservados antes desse ponto sejam adequados para atender a ambos 
os receptores. Por exemplo, se o receptor A já tiver feito uma reserva que oferece um atraso garantido de 
menos de 100 ms, e anova solicitação do receptor B for para um atraso de menos de 200 ms, então nenhuma 
nova reserva é necessária. Por outro lado, se a nova solicitação fosse para um atraso de menos de 50 ms, 
então o roteador primeiro teria que verificar se poderia aceitar a solicitação e, se pudesse, ele enviaria a 
solicitação adiante. Da próxima vez que o receptor A pedisse um atraso de no mínimo 100 ms, o roteador 
não precisaria passar essa solicitação adiante. Em geral, as reservas podem ser fundidas dessa maneira para 
atender às necessidades de todos os receptores localizados após o ponto de fusão, no sentido do fluxo. 

Se também houver vários emissores na árvore, os receptores precisam coletar as TSpecs de todos 
os emissores e fazer uma reserva que seja grande o bastante para acomodar o tráfego de todos eles. 
Contudo, isso não necessariamente significa que as TSpecs precisam ser somadas. Por exemplo, em 
uma conferência de áudio com dez palestrantes, não há muito sentido em alocar recursos suficientes 
para transportar dez fluxos de áudio, pois o resultado de dez pessoas falando ao mesmo tempo seria 
incompreensível. Assim, poderíamos imaginar uma reserva grande o suficiente para acomodar dois 
palestrantes, e não mais. O cálculo da TSpec geral correta a partir de todas as TSpecs emissoras logica- 
mente é um processo específico por aplicação. Além disso, podemos só estar interessados em ouvir um 
subconjunto de todos os palestrantes. O RSVP possui diferentes estilos de reserva para lidar com opções 
como “Reservar recursos para todos os palestrantes”, “Reservar recursos para n palestrantes quaisquer”, 
e “Reservar recursos apenas para os palestrantes A e B”. 
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Classificação e escalonamento de pacotes 

Depois de descrevermos nosso tráfego e nosso serviço de rede desejado e de termos instalado uma reserva 
adequada em todos os roteadores no caminho, a única coisa que resta é que os roteadores realmente 
entreguem o serviço solicitado aos pacotes de dados. Existem duas coisas que precisam ser feitas: 


e Associar cada pacote à reserva apropriada, para que ele possa ser tratado corretamente, um 
processo conhecido como classificação de pacotes. 

e Gerenciar os pacotes nas filas de modo que eles recebam o serviço que foi solicitado, um processo 
conhecido como escalonamento de pacotes. 


A primeira parte é feita examinando-se até cinco campos no pacote: o endereço de origem, o en- 
dereço de destino, o número do protocolo, a porta de origem e a porta de destino. (No IPv6, é possível 
que o campo RótuloFluxo no cabeçalho possa ser usado para permitir que a busca seja feita com base 
em uma única chave, mais curta.) Com base nessa informação, o pacote pode ser colocado na classe 
apropriada. Por exemplo, ele pode ser classificado nas classes de carga controlada, ou pode fazer parte 
de um fluxo garantido que precisa ser tratado separadamente de todos os outros fluxos garantidos. 
Resumindo, existe um mapeamento entre a informação específica relativa ao fluxo no cabeçalho do 
pacote e um único identificador de classe, que determina como o pacote será tratado na fila. Para fluxos 
garantidos isso pode ser um mapeamento um para um, enquanto para outros serviços o mapeamento 
poderia ser muitos para um. Os detalhes da classificação são bastante relacionados aos detalhes do 
gerenciamento de fila. 


ONDE ELES ESTÃO AGORA? 


RSVP E SERVIÇOS INTEGRADOS 

O RSVP e a arquitetura de serviços integrados, enquanto escrevíamos este livro, ainda não haviam sido 
amplamente implantados, em parte por questões de escalabilidade descritas ao final desta seção. De fato, 
é comum afirmar que elas estão mortas como tecnologias. Porém, pode ser prematuro escrever agora os 
obituários para o RSVP e os serviços integrados. 

Separado do IntServ, o RSVP tem sido muito empregado como um protocolo para estabelecer 
caminhos MPLS para fins de engenharia de tráfego, conforme descrevemos na Seção 4.3. Por esse motivo 
apenas, a maioria dos roteadores na Internet tem algum tipo de implementação do RSVP Porém, essa é, 
provavelmente, a extensão total da implantação do RSVP na Internet no momento em que escrevíamos este 
livro. Esse uso do RSVP é bastante independente do IntServ, mas pelo menos demonstra que o protocolo 
em si é passível de implantação. 

Existe evidência de que o RSVP e o IntServ possam ter uma segunda chance, mais de 10 anos após terem 
sido propostos inicialmente. Por exemplo, a IETF está padronizando extensões ao RSVP para dar suporte às 
reservas agregadas — extensões que atacam diretamente as questões de escalabilidade que foram levantadas 
sobre o RSVP e o IntServ no passado. E também existe um suporte cada vez maior para RSVP como protocolo 
de reserva de recurso em produtos comerciais. 

Podemos identificar diversos fatores que poderão levar a uma maior adoção do RSV e do IntServem 
um futuro próximo. Primeiro, as aplicações que realmente exigem QoS, como Voz sobre IP conferência de 
vídeo em tempo real e vídeo de entretenimento, são muito mais difundidas do que há 10 anos, criando uma 
demanda maior por mecanismos sofisticados de QoS. Segundo, o controle de admissão — que permite que 
a rede diga não a uma aplicação quando os recursos são escassos — é compatível com aplicações que não 
podem funcionar a menos que haja recursos suficientes. A maioria dos usuários de telefones IP por exemplo, 
preferiria receber um sinal de ocupado da rede do que fazer com que uma chamada prossiga com uma 
qualidade inaceitavelmente ruim, e um operador da rede preferiria enviar um sinal de ocupado a um usuário 
do que fornecer uma qualidade ruim a um grande número de usuários. Um terceiro fator são os elevados 
requisitos em termos de recursos das novas aplicações, como entrega de vídeo em alta definição: como elas 
precisam tanto que a largura de banda funcione bem, pode ser mais econômico criar redes capazes de dizer 
não ocasionalmente do que fornecer largura de banda suficiente para atender a todas as demandas de 
aplicação possíveis. Porém, essa é uma escolha complexa, e a discussão sobre o valor do controle 
de admissão, e de usar o RSVP e o IntServ como as ferramentas para fornecê-lo, provavelmente continuará 
por mais algum tempo. 
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Deve ficar claro que algo tão simples como uma fila FIFO em um roteador será inadequado para 
oferecer muitos serviços diferentes e diferentes níveis de atraso dentro de cada serviço. Várias outras es- 
tratégias de gerenciamento de fila mais sofisticadas foram discutidas na Seção 6.2, e alguma combinação 
destas provavelmente será usada em um roteador. 

Os detalhes do escalonamento de pacotes, de preferência, não devem ser especificados no modelo de 
serviço. Ao invés disso, essa é uma área na qual os desenvolvedores podem tentar fazer coisas criativas 
para realizar o modelo de serviço de modo eficiente. No caso do serviço garantido, estabeleceu-se 
que uma estratégia de enfileiramento justo ponderado, em que cada fluxo recebe sua própria fila in- 
dividual com certa fatia do enlace, oferecerá um atraso fim a fim garantido, que pode ser prontamente 
calculado. Para a carga controlada, esquemas mais simples podem ser utilizados. Uma possibilidade 
inclui o tratamento de todo o tráfego de carga controlada como um único fluxo agregado (no que diz 
respeito ao mecanismo de escalonamento), com o peso para esse fluxo sendo definido com base na 
quantidade total de tráfego admitida na classe de carga controlada. O problema é mais difícil quando 
você considera que, em um único roteador, muitos serviços diferentes provavelmente serão fornecidos 
ao mesmo tempo, e que cada um desses serviços pode exigir um algoritmo de escalonamento diferente. 
Assim, algum algoritmo geral de gerenciamento de fila é necessário para gerenciar os recursos entre os 
diferentes serviços. 


Aspectos de escalabilidade 

Embora a arquitetura de Serviços Integrados e o RSVP tenham representado uma melhoria significativa 
no modelo de serviço de melhor esforço do IP muitos provedores de serviço da Internet sentiram que ele 
não era o modelo certo a se implantar. O motivo para essa reserva está relacionado com um dos objetivos 
principais de projeto do IP: escalabilidade. No modelo de serviço de melhor esforço, os roteadores na 
Internet armazenam pouco ou nenhum estado sobre os fluxos individuais que passam por eles. Assim, 
à medida que a Internet cresce, a única coisa que os roteadores precisam fazer para acompanhar esse 
crescimento é mover mais bits por segundo e lidar com tabelas de roteamento maiores, mas o RSVP 
aumenta a possibilidade de que cada fluxo passando por um roteador tenha uma reserva corres- 
pondente. Para entender a seriedade desse problema, suponha que cada fluxo em um enlace OC-48 
(2,5 Gbps) represente um fluxo de áudio de 64 Kbps. A quantidade de tais fluxos é: 


2,5x10º /64x10° =39.000 


Cada uma dessas reservas precisa de alguma quantidade de estado, que precisa ser armazenado 
na memória e atualizado periodicamente. O roteador precisa classificar, policiar e enfileirar cada um 
desses fluxos. As decisões de controle de admissão precisam ser feitas toda vez que tal fluxo solicita 
uma reserva. E alguns mecanismos são necessários para “frear” os usuários, de modo que não façam 
reservas arbitrariamente grandes por longos períodos de tempo.º 

Esses problemas de escalabilidade, no momento em que este livro era escrito, preveniram a im- 
plantação generalizada do IntServ. Devido a esses problemas, outras abordagens que não exigem tanto 
estado “por fluxo” foram desenvolvidas. A próxima seção discute diversas dessas técnicas. 

& 


6.5.3 Serviços diferenciados (EF, AF) uas apêndice e: 


ATM 

Enquanto a arquitetura de Serviços Integrados reserva recursos a fluxos individuais, o modelo de Serviços 
Diferenciados (Differentiated Services, normalmente chamado DiffServ, para abreviar) aloca recursos 
a um pequeno número de classes de tráfego. De fato, algumas técnicas propostas para o DiffServ sim- 
plesmente dividem o tráfego em duas classes. Essa é uma abordagem eminentemente sensível de se 
adotar: se você considerar a dificuldade que os operadores de rede experimentam apenas tentando 
manter uma inter-rede de melhor esforço funcionando sem percalços, faz sentido acrescentar o modelo 
de serviço em pequenos incrementos. 


$Cobrar pela reserva seria um modo de frear usuários, coerente com o modelo de telefonia de cobrar por cada ligação 
telefônica. Esse não é o único modo de frear usuários, e a cobrança por chamada é considerada um dos principais custos de 
operação da rede telefônica. 
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Suponha que tenhamos decidido melhorar o modelo de serviço de melhor esforço acrescentando 
apenas uma nova classe, que chamaremos “premium”. Logicamente, precisaremos de alguma maneira 
de descobrir quais pacotes são premium e quais são os antigos pacotes de melhor esforço. Em vez de 
usar um protocolo como o RSVP para dizer a todos os roteadores que algum fluxo está enviando pacotes 
premium, seria muito mais fácil se os pacotes pudessem simplesmente se identificar ao roteador quando 
chegarem. Isso obviamente poderia ser feito usando um bit no cabeçalho do pacote — se esse bit for 1, o 
pacote é um pacote premium; se for 0, o pacote é de melhor esforço. Com isso em mente, existem duas 
perguntas que precisam ser respondidas: 


e Quem marca o bit premium, e sob quais circunstâncias? 
e Oque um roteador faz de diferente quando ele vê um pacote com o bit marcado? 


Há muitas respostas possíveis para a primeira pergunta, mas uma técnica comum é marcar o bit 
em um limite administrativo. Por exemplo, o roteador na borda da rede de um provedor de serviços da 
Internet poderia marcar esse bit para pacotes que chegam a uma interface conectada à rede de deter- 
minada empresa. O provedor de serviços da Internet poderia fazer isso porque essa empresa pagou por 
um nível de serviço mais alto do que o melhor esforço. Também é possível que nem todos os pacotes 
sejam marcados como premium; por exemplo, o roteador poderia ser configurado para marcar pacotes 
como premium até alguma taxa máxima, e deixar todos os pacotes em excesso como melhor esforço. 

Supondo que os pacotes foram marcados de alguma maneira, o que os roteadores que encontram 
pacotes marcados fazem com eles? Aqui, novamente existem muitas respostas. Na verdade, a IETF está 
padronizou um conjunto de comportamentos do roteador a serem aplicados aos pacotes marcados. Estes 
são chamados comportamentos por salto (PHBs — hop behaviors), um termo que indica que eles definem 
o comportamento de roteadores individuais, ao invés de serviços fim a fim. Como existe mais de um 
comportamento novo, existe também uma necessidade de mais de 1 bit no cabeçalho do pacote para 
dizer aos roteadores qual comportamento aplicar. A IETF decidiu usar o antigo byte TOS do cabeçalho 
IP que não foi muito utilizado, e redefini-lo. Seis bits desse byte foram alocados para os pontos de código 
DiffServ (DSCP -DiffServ Code Points), onde cada DSCP é um valor de 6 bits que identifica determinado 
PHB a ser aplicado a um pacote. (Os dois bits restantes são usados pela ECN, descrita na Seção 6.4.2.) 


O PHB de encaminhamento expresso (EF) 

Um dos PHBs mais simples de se explicar é conhecido como encaminhamento expresso (EF — Expedited 
Forwarding). Os pacotes marcados para tratamento EF devem ser encaminhados pelo roteador com o 
mínimo de atraso ou perda. A única maneira pela qual um roteador pode garantir isso a todos os pacotes 
EF é se a taxa de chegada dos pacotes EF no roteador for estritamente limitada para ser menor que a taxa 
em que o roteador pode encaminhar pacotes EF Por exemplo, um roteador com uma interface de 100 
Mbps precisa ter certeza de que a taxa de chegada dos pacotes EF destinados para essa interface nunca ex- 
ceda 100 Mbps. Ele também pode querer garantir que a taxa será um pouco abaixo de 100 Mbps, de modo 
que ocasionalmente tenha tempo para enviar outros pacotes, como atualizações de roteamento. 

A limitação de taxa dos pacotes EF é alcançada configurando-se os roteadores na borda de um 
domínio administrativo para permitir certa taxa máxima de chegadas de pacote EF no domínio. Uma 
abordagem simples, embora conservadora, seria garantir que a soma das taxas de todos os pacotes 
EF que entram no domínio seja menor que a largura de banda do enlace mais lento no domínio. Isso 
garantiria que, até mesmo no pior caso, onde todos os pacotes EF convirjam para o enlace mais lento, 
ele não seja sobrecarregado e possa oferecer o comportamento correto. 

Existem várias estratégias de implementação possíveis para o comportamento de EF Uma é dar aos pa- 
cotes EF estrita prioridade sobre todos os outros pacotes. Outra é realizar o enfileiramento justo ponderado 
entre os pacotes EF e os outros pacotes, com o peso da fila de EF sendo definido com valor suficientemente 
alto para que todos os pacotes EF possam ser entregues rapidamente. Isso tem uma vantagem em relação 
à prioridade estrita: os pacotes não EF podem ter garantias de que receberão algum acesso ao enlace, 
mesmo que a quantidade de tráfego EF seja excessiva. Isso pode significar que os pacotes EF acabem 
não obtendo exatamente o comportamento especificado, mas também poderia evitar que o tráfego de 
roteamento essencial seja bloqueado fora da rede no caso de uma carga excessiva de tráfego EE 
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O PHB de encaminhamento garantido (AF) 

O PHB de encaminhamento garantido (AF — Assured Forwarding) tem suas raízes em uma técnica conhe- 
cida como “RED com dentro e fora” (RIO — RED with In and Out) ou “RED ponderada”, ambos melhorias 
ao algoritmo RED básico da Seção 6.4.2. A Figura 6.26 mostra como funciona o algoritmo RIO. Assim 
como a Figura 6.17, vemos a probabilidade de descarte no eixo y aumentando conforme o tamanho 
médio da fila aumenta com o eixo x. Mas, agora, para nossas duas classes de tráfego, temos duas curvas 
de probabilidade de descarte separadas. O algoritmo RIO chama as duas classes de “dentro” e “fora” 
por motivos que logo se tornarão claros. Como a curva de “fora” tem um LimiarMínimo inferior ao da 
curva de “dentro”, fica claro que, sob níveis de congestionamento baixos, somente os pacotes marcados 
com “fora” serão descartados pelo algoritmo RED. Se o congestionamento se tornar mais sério, uma 
porcentagem mais alta de pacotes de “fora” será descartada, e se o tamanho médio da fila ultrapassar 
Mingentro O algoritmo RED também começa a descartar pacotes de “dentro”. 

O motivo para chamar essas duas classes de pacotes de “dentro” e “fora” vem do modo como os pacotes 
são marcados. Já observamos que a marcação de pacotes pode ser realizada por um roteador na borda de 
um domínio administrativo. Podemos pensar nesse roteador como estando no limite entre um provedor de 
serviços de rede e algum cliente dessa rede. O cliente poderia estar em qualquer outra rede, por exemplo, a 
rede de uma empresa ou de outro provedor de serviços de rede. O cliente e o provedor de serviços de rede 
combinam algum tipo de perfil para o serviço garantido (e talvez o cliente pague ao provedor de serviços 
de rede por esse perfil). O perfil poderia ser algo como “Cliente X tem permissão para enviar até y Mbps de 
tráfego garantido”, ou poderia ser muito mais complexo. Qualquer que seja o perfil, o roteador de borda 
pode claramente marcar os pacotes que chegam desse cliente como estando dentro ou fora do perfil. No 
exemplo mencionado, desde que o cliente envie menos de y Mbps, todos os seus pacotes serão marcados 
como “dentro”, mas quando essa taxa é ultrapassada, os pacotes em excesso serão marcados como “fora”. 

A combinação de um “medidor de perfil” na borda e o algoritmo de RIO em todos os roteadores da 
rede do provedor de serviços deverá oferecer ao cliente uma boa confiança (mas não uma garantia) 
de que os pacotes dentro de seu perfil poderão ser entregues. Em particular, se a maioria dos pacotes, 
incluindo aqueles enviados pelos clientes que não pagaram a mais para estabelecer um perfil, forem 
pacotes “fora”, então normalmente o mecanismo RIO atuará para manter o congestionamento baixo o 
suficiente para que os pacotes “dentro” raramente sejam descartados. Naturalmente, é preciso haver 
largura de banda suficiente na rede para que os pacotes “dentro” raramente sejam capazes de conges- 
tionar um enlace a ponto de o RIO começar a descartar pacotes “dentro”. 

Assim como na técnica de RED, a eficácia de um mecanismo como RIO depende até certo ponto da 
escolha de parâmetros corretos, e existem muito mais parâmetros a definir para o algoritmo de RIO. 
Exatamente o quão bem o esquema funcionará nas redes em produção é algo que não é possível dizer 
na época em que este livro foi escrito. 

Uma propriedade interessante do algoritmo RIO é que ele não muda a ordem dos pacotes “dentro” 
e “fora”. Por exemplo, se uma conexão TCP estiver enviando pacotes através de um medidor de perfil, 
e alguns pacotes estiverem sendo marcados como “dentro” enquanto outros são marcados como “fora”, 
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esses pacotes receberão probabilidades de descarte diferentes nas filas de roteador, mas serão entregues 
ao receptor na mesma ordem em que foram enviados. Isso é importante para a maioria das implemen- 
tações do TCP que funcionam muito melhor quando os pacotes chegam em ordem, mesmo que sejam 
projetados para lidar com a falta de ordem. Observe também que mecanismos como a retransmissão 
rápida podem ser disparados falsamente devido à falta de ordem. 

A ideia do algoritmo RIO pode ser generalizada para oferecer mais de duas curvas de probabilidade 
de descarte, e essa é a ideia por trás da técnica conhecida como RED ponderada (WRED - Weighted RED). 
Nesse caso, o valor do campo DSCP é usado para a escolha de uma dentre várias curvas de probabilidade 
de descarte, de modo que várias classes de serviço diferentes podem ser oferecidas. 

Uma terceira forma de oferecer serviços diferenciados é usar o valor de DSCP para determinar em 
que fila será colocado um pacote em um escalonador de enfileiramento justo ponderado, conforme 
descrevemos na Seção 6.2.2. Como um caso muito simples, poderíamos usar um valor de ponto de 
código para indicar a fila de melhor esforço e um segundo valor de ponto de código para selecionar a 
fila premium. Depois, precisamos escolher um peso para a fila premium, fazendo com que os pacotes 
premium recebam melhor serviço do que os pacotes de melhor esforço. Isso depende da carga de pacotes 
premium oferecida. Por exemplo, se dermos à fila premium um peso de 1 e à fila de melhor esforço um 
peso de 4, isso garante que a largura de banda disponível para os pacotes premium seja: 


premium T premium ( premium + P emae ) 
=1/(1+4) 
=0,2 


ONDE ELES ESTÃO AGORA? 


O SUCESSO SILENCIOSO DO DIFFSERV 

Por volta de 2003, muitas pessoas estavam prontas para declarar que o DiffServ estava morto. A conferência 
ACM SIGCOMM desse ano, uma das conferências de pesquisa em redes mais prestigiosas, incluiu um 
workshop com o título provocativo “RIPQOS” — o nome oficial do workshop era “Revisiting IP QoS” (revisitando 
o Qos do IP), mas a implicação de que o QoS poderia estar pronto para descansar em paz (RIP — rest in peace) 
estava clara no anúncio do workshop. Porém, assim como Mark Twain brincou que os relatos de sua morte 
eram bastante exagerados, parece que a morte da QosS no IP e do DiffServ em particular, também foi exagerada. 

Grande parte do pessimismo sobre o DiffServ surgiu do fato de que ele não foi implantado em qualquer 
extensão significativa pelos provedores de serviço da Internet. Não apenas isso, mas o fato de que as aplicações 
em tempo real, como a telefonia IP e o streaming de vídeo, pareceram estar funcionando muito bem pela 
Internet, sem quaisquer mecanismos de Qos, fazendo com que questionemos se a QoS sequer será realmente 
necessária. Em parte, isso é o resultado de uma implantação agressiva de enlaces e roteadores com elevada 
largura de banda por muitos ISPs, especialmente durante os anos de crescimento no final da década de 1990. 

Para ver onde o DiffServ teve sucesso, é preciso examinar fora dos backbones do ISP Por exemplo, 
empresas que implantaram soluções de telefonia IP — e há dezenas de milhões de telefones IP de classe 
empresarial em uso no momento em que este livro foi escrito - normalmente, utilizam o comportamento EF 
para os pacotes de mídia de voz, para garantir que eles não sejam atrasados quando compartilharem enlaces 
com outro tráfego. O mesmo acontece para muitas soluções de Voz sobre IP residenciais: simplesmente para 
ter prioridade no enlace de saída da residência (por exemplo, a direção “lenta” de um enlace DSL), é comum 
que o terminal de voz defina o DSCP como EF e que o roteador de um consumidor conectado a um enlace de 
banda larga utilize DiffServ para fornecer baixa latência e jitter a esses pacotes. Existem até mesmo algumas 
grandes companhias telefônicas dos Estados Unidos que migraram seus serviços de voz tradicionais para 
redes IP com DiffServ fornecendo meios para proteger a QoS do tráfego de voz. 

Existem outras aplicações, além da voz, que estão se beneficiando do DiffServ, principalmente serviços de 
dados comerciais, e sem dúvida o amadurecimento do vídeo baseado em IP nos próximos anos oferecerá outro 
impulsionador. Em geral, dois fatores fazem com que a implantação do DiffServ alha a pena: uma alta demanda 
por garantia de QoS pela aplicação e uma falta de garantia de que a largura de banda do enlace será suficiente para 
entregar essa QoS a todo o tráfego atravessando o enlace. É importante observar que o DiffServ, como qualquer 
outro mecanismo de Qos, não pode criar largura de banda — tudo o que ele pode fazer é garantir que a largura de 
banda que existe seja alocada preferencialmente às aplicações que possuem necessidades de QoS mais exigentes. 
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Ou seja, efetivamente reservamos 20% do enlace para pacotes premium, de modo que, se a carga ofe- 
recida de tráfego premium for, na média, apenas 10% do enlace, então o tráfego premium se comportará 
como se estivesse executando em uma rede com muito pouca carga, e o serviço será muito bom. Em 
particular, o atraso experimentado pela classe premium pode ser baixo, pois nesse cenárioa WFQ tentará 
transmitir pacotes premium assim que eles chegarem. Por outro lado, se a carga de tráfego premium 
fosse 30%, ele se comportaria como uma rede bastante sobrecarregada, e o atraso poderia ser muito alto 
para os pacotes premium - pior ainda do que para os chamados pacotes de melhor esforço. Assim, o 
conhecimento da carga oferecida e a definição cuidadosa dos pesos são importantes para esse tipo de 
serviço. Porém, observe que a técnica segura é ser muito conservador na definição do peso para a fila 
premium. Se esse peso se tornar muito alto em relação à carga esperada, ele oferecerá uma margem de 
erro e ainda assim não evitará que o tráfego de melhor esforço use qualquer largura de banda que tenha 
sido reservada para o tráfego premium mas que não esteja sendo usada por pacotes premium. 

Assim como na técnica WRED, podemos generalizar essa técnica baseada em WFQ para permitir mais 
de duas classes representadas por diferentes pontos de código. Além disso, podemos combinar a ideia 
de um seletor de fila com uma preferência de descarte. Por exemplo, com 12 pontos de código, podemos 
ter quatro filas com diferentes pesos, cada uma com três preferências de descarte. É exatamente isso 
que a IETF fez na definição do “serviço garantido”. 


QUALIDADE DE SERVIÇO ATM 





O ATM é uma tecnologia um tanto menos importante hoje do que há 10 anos, mas uma de suas 
contribuições reais foi na área de QoS. Em alguns aspectos, o fato de que o ATM foi projetado com 
capacidades de QoS muito ricas foi uma das coisas que estimularam o interesse no Qos para IP Isso também 
ajudou a adoção inicial do ATM. 

Em muitos aspectos, as capacidades de QoS que são fornecidas nas redes ATM são semelhantes 
àquelas oferecidas em uma rede IP usando serviços integrados. Porém, os órgãos de padronização do ATM 
apareceram com um total de cinco classes de serviço, em comparação com as três da IETE* As cinco classes 
de serviço do ATM são: 


e Taxa Constante de Bits (Constant Bit Rate ou CBR) 

e Taxa Variável de Bits - tempo real (Variable Bit Rate-real-time ou VBR-rt) 

e Taxa Variável de Bits - tempo não real (Variable Bit Rate-non-real-time ou VBR-nrt) 
e Taxa de Bits Disponível (Available Bit Rate ou ABR) 

e Taxa de Bits Não Especificada (Unspecified Bit Rate ou UBR) 


A maioria das classes de serviço ATM e IP é muito semelhante, mas uma delas, a ABR, não possui 
equivalente real no IP Explicamos essa classe com detalhes a seguir. A VBR-rt é muito semelhante à classe 
de serviço garantido nos serviços integrados do IP Os parâmetros exatos que são usados para estabelecer 
um circuito virtual VBR-rt são ligeiramente diferentes daqueles usados para criar uma reserva de serviço 
garantido, mas a ideia básica é a mesma. O tráfego gerado pela origem é caracterizado por um balde de 
fichas, e o atraso total máximo exigido da rede é especificado. A CBR também é semelhante ao serviço 
garantido, exceto que as fontes de tráfego CBR deverão enviar dados a uma taxa constante. Observe que este 
é realmente um caso especial de VBR, onde a taxa de pico da origem e a taxa média de transmissão são iguais. 

AVBR-nrt é muito semelhante ao serviço de carga controlada do IP Novamente, o tráfego gerado pela 
origem é caracterizado por um balde de fichas, mas não existe a mesma garantia de atraso rígida da VBR-rt, 
ou o serviço garantido do IP A UBR é o serviço de melhor esforço do ATM. 

Finalmente, chegamos à ABR, que é mais do que apenas uma classe de serviço; ela também define um 
conjunto de mecanismos de controle de congestionamento. Ela é muito complexa, de modo que esta seção 
aborda apenas alguns dos pontos principais. 

Os mecanismos da ABR operam sobre um circuito virtual trocando células ATM especiais, chamadas 
células de gerenciamento de recursos (RM — Resource Management) entre a origem e o destino do circuito 
virtual. O objetivo do envio de células RM é obter informações sobre o estado do congestionamento na rede 
até a origem, de modo que a rede possa enviar tráfego em uma taxa apropriada. Nesse sentido, as células 





*Contamos o melhor esforço como uma classe de serviço, junto com a carga controlada e o serviço garantido. 
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RM são um mecanismo explícito de feedback de congestionamento. Isso é semelhante ao DECbit (ver Seção 
6.4.1), mas difere do uso do TCP com feedback implícito, que depende das perdas de pacotes para detectar o 
congestionamento. Isso também é semelhante ao novo mecanismo de partida rápida para o TCP descrito na 
Seção 6.3.2. 

Inicialmente, a origem envia a célula ao destino e inclui nela a taxa em que gostaria de enviar as células 
de dados. Os switches ao longo do caminho examinam a taxa solicitada e decidem se recursos suficientes 
estão disponíveis para lidar com essa taxa, com base na quantidade de tráfego sendo transportada em outros 
circuitos. Se houver recursos suficientes à disposição, a célula RM é passada adiante sem modificação; caso 
contrário, a taxa solicitada é diminuída antes que a célula seja passada adiante. Após chegar ao destino, a 
célula RM retorna e é enviada de volta à origem, que com isso descobre em que taxa seus dados podem ser 
enviados. 

A intenção da ABR é permitir que a origem aumente ou diminua sua taxa alocada, conforme ditarem as 
condições. Como consequência, as células RM são enviadas periodicamente e podem conter taxas solicitadas 
mais altas ou mais baixas. Além disso, a taxa em que uma origem tem permissão para enviar diminui com 
o tempo se não for usada. Em geral, os algoritmos proprietários nos switches determinam as taxas que são 
colocadas nas células RM enquanto ela passam pelos switches; os algoritmos se baseiam em uma série 
de informações, como a ocupação atual do buffer e as taxas de chegada medidas nos circuitos virtuais 
atualmente ativos. Esses algoritmos, como é normal para algoritmos de controle de congestionamento, 
buscam maximizar a vazão e manter o atraso e a perda em níveis baixos. 

Dado o declínio relativo do ATM nas redes reais de hoje, o ponto interessante da QoS do ATM é quantos 
mecanismos são comuns para tecnologias diferentes. Os mecanismos que são encontrados na QoS do ATM 
e do IP incluem controle de admissão, algoritmos de escalonamento, controladores de balde de fichas e 
mecanismos de feedback explícito de congestionamento. 





6.5.4 Controle de congestionamento baseado em equação 


Concluímos nossa discussão sobre QoS retornando completamente até o controle de congestionamento 
TCB mas desta vez no contexto das aplicações de tempo real. Lembre-se que o TCP ajusta a janela de 
congestionamento do emissor (e, portanto, a taxa em que ele pode transmitir) em resposta a eventos de 
ACK e expiração do tempo limite. Uma das vantagens dessa abordagem é que ela não exige cooperação 
dos roteadores da rede; ela é uma estratégia baseada puramente no host. Tal estratégia complementa 
os mecanismos de QosS que consideramos porque (1) as aplicações podem usar hoje soluções baseadas 
em host, antes que os mecanismos de QoS sejam amplamente implantados, e (2) até mesmo com Diff- 
Serv totalmente implantado, ainda é possível que uma fila de roteador exceda sua capacidade real, e 
gostaríamos que aplicações de tempo real reagissem de um modo razoável se isso acontecer. 

Embora desejássemos tirar proveito do algoritmo de controle de congestionamento do TCP o próprio 
TCP não é apropriado para aplicações de tempo real. Um motivo é que o TCP é um protocolo confiável, 
e aplicações de tempo real normalmente não podem admitir os atrasos introduzidos pela retransmissão. 
Porém, e se desacoplássemos o TCP do seu mecanismo de controle de congestionamento, ou seja, 
incluíssemos um controle de congestionamento tipo TCP a um protocolo não confiável, como o UDP? 
As aplicações de tempo real poderiam fazer uso de tal protocolo? 

Por um lado, essa é uma ideia atraente, pois faria com que os fluxos de tempo real competissem de 
forma justa com os fluxos TCP A alternativa (que acontece hoje) é que as aplicações de vídeo usem UDP 
sem qualquer forma de controle de congestionamento e, por conseguinte, roubem largura de banda dos 
fluxos TCP que recuam na presença do congestionamento. Por outro lado, o comportamento de “dente 
de serra” do algoritmo de controle de congestionamento do TCP (ver Figura 6.9) não é apropriado para 
aplicações de tempo real: isso significa que a taxa em que a aplicação transmite está constantemente 
subindo e descendo. Ao contrário, as aplicações de tempo real funcionam melhor quando são capazes 
de sustentar uma taxa de transmissão uniforme por um período de tempo relativamente longo. 

Seria possível obter o melhor dos dois mundos: compatibilidade com o controle de congestionamen- 
to TCP por questão de justiça, sustentando uma taxa de transmissão uniforme para satisfazer a questão 
da aplicação? Trabalhos recentes sugere que a resposta é sim. Especificamente, vários algoritmos 
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de controle de congestionamento, chamados “amigáveis a TCP”, foram propostos. Esses algoritmos 
possuem dois objetivos principais. Um é adaptar-se lentamente à janela de congestionamento. Isso é 
feito adaptando-se por períodos de tempo relativamente mais longos (por exemplo, um RTT), e não 
com base em cada pacote. Isso torna a taxa de transmissão mais uniforme. O segundo é ser amigável 
a TCP no sentido de ser justo com os fluxos TCP concorrentes. Essa propriedade normalmente é 
imposta garantindo-se que o comportamento do fluxo seja aderente a uma equação que modela o 
comportamento do TCP Logo, essa técnica, às vezes, é chamada controle de congestionamento baseado 
em equação. 

Vimos uma forma simplificada da equação da taxa de transmissão do TCP na Seção 6.3. O leitor 
interessado deve consultar a seção “Leitura adicional”, ao final deste capítulo, para obter os detalhes 
sobre o modelo completo. Para nossos propósitos, a forma exata da equação é menos interessante do 
que sua forma geral: 


que diz que, para ser amigável ao TCP a taxa de transmissão precisa ser inversamente proporcional ao 
tempo de ida e volta (RTT) e à raiz quadrada da taxa de perda (p). Em outras palavras, para montar um 
mecanismo de controle de congestionamento a partir desse relacionamento, o receptor precisa informar 
periodicamente ao emissor a taxa de perda que está experimentando (por exemplo, ele poderia informar 
que deixou de receber 10% dos últimos 100 pacotes), e o emissor então ajusta sua taxa de transmissão 
para cima ou para baixo, de modo que esse relacionamento continua a ser mantido. Naturalmente, 
ainda fica a critério da aplicação adaptar-se a essas mudanças na taxa disponível, mas, como veremos 
no próximo capítulo, muitas aplicações de tempo real são bastante adaptáveis. 


6.6 Resumo 


Como vimos, a questão de alocação de recursos não é apenas fundamental para as redes de compu- 
tadores, mas também é um problema muito difícil. Este capítulo examinou dois aspectos da alocação 
de recursos. O primeiro, o controle de congestionamento, trata da prevenção da degradação geral do 
serviço quando a demanda por recursos pelos hosts ultrapassa a disponibilidade da rede. O segundo 
aspecto é a provisão de diferentes qualidades de serviço para aplicações que precisam de mais garantias 
do que aquelas fornecidas pelo modelo de melhor esforço. 

A maior parte dos mecanismos de controle de congestionamento tem como alvo o modelo de 
serviço de melhor esforço da Internet de hoje, onde a responsabilidade principal pelo controle de 
congestionamento recai sobre os nós finais da rede. Normalmente, a origem usa o feedback — descoberto 
implicitamente pela rede ou enviado explicitamente por um roteador — para ajustar a carga colocada 
sobre a rede; é exatamente isso que o mecanismo de controle de congestionamento do TCP faz. 

Independentemente do que exatamente os nós finais estão fazendo, os roteadores implementam uma 
disciplina de enfileiramento que controla quais pacotes são transmitidos e quais pacotes são descartados. 
Às vezes, esse algoritmo de enfileiramento é sofisticado o bastante para segregar o tráfego (por exemplo, 
WFQ) e, em outros casos, o roteador tenta monitorar seu tamanho de fila e depois sinaliza ao host de 
origem quando o congestionamento está para ocorrer (por exemplo, gateways RED e DEChit). 

Técnicas emergentes de qualidade de serviço tem como objetivo fazer muito mais do que apenas 
controlar o congestionamento. Seu objetivo é permitir que aplicações com requisitos bastante variáveis 
de atraso, perda e vazão, tenham esses requisitos atendidos através de novos mecanismos dentro da 
rede. A técnica de Serviços Integrados (Integrated Services) permite que fluxos de aplicações individuais 
especifiquem suas necessidades aos roteadores usando um mecanismo de sinalização explícita (RSVP), 
enquanto a técnica de Serviços Diferenciados (Differentiated Services) distribui os pacotes dentre 
um pequeno número de classes, que recebem tratamento diferenciado nos roteadores. Os serviços 
diferenciados, de longe, é a técnica mais empregada, e mesmo assim nem DiffServ nem IntServ foram 
implantados de forma ampla na Internet pública. 
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Talvez a melhor pergunta que devamos fazer seja o quanto podemos esperar da rede e quanta respon- 
sabilidade recairá por fim sobre os hosts finais. As estratégias baseadas em reservas certamente têm 
a vantagem de prover qualidades de serviço mais variadas do que os esquemas atuais, baseados em 
feedback; ser capaz de dar suporte a qualidades de serviço diferentes é um motivo forte para colocar 
mais funcionalidade nos roteadores da rede. Isso significa que os dias do controle de congestiona- 
mento fim a fim (tipo TCP) estão contados? Isso parece muito pouco provável. O TCP e as aplicações 
que o utilizam estão bem enraizados, e em muitos casos não precisam de muita ajuda da rede. Além 
disso, é muito improvável que todos os roteadores em uma rede mundial e heterogênea como a In- 
ternet implementem exatamente o mesmo algoritmo de reserva de recursos. Por fim, parece que as 
extremidades terão que se cuidar por conta própria, pelo menos até certo ponto. O princípio fim a 
fim argumenta que devemos ser muito seletivos a respeito da inclusão de funcionalidade adicional 
dentro da rede. É muito interessante imaginarmos as consequências disso nos próximos anos, em 
mais áreas do que somente alocação de recursos. 

De certa forma, a técnica de serviços diferenciados representa o meio-termo entre a inteligência 
absolutamente mínima na rede e a quantidade significativa de inteligência (e informações de estado 
armazenadas) que é necessária em uma rede de serviços integrados. Implantações dos serviços 
integrados e RSVP podem ser encontradas atualmente, mas apenas em ambientes muito res- 
tritos (principalmente, em redes corporativas). Uma questão importante é se a técnica de serviços 
diferenciados atenderá aos requisitos das aplicações mais exigentes. Por exemplo, se um provedor 
de serviços estiver tentando oferecer um serviço de vídeosob demandaem grande escala por uma 
rede IP as técnicas de serviços diferenciados serão adequadas para prover a qualidade de serviço 
esperada pelos usuários da televisão tradicional? É provável que ainda mais opções de QoS, com 
graus variados de inteligência na rede, tenham de ser exploradas. 

Há algumas tendências que parecem apontar na direção dos sistemas finais encarregados de suas 
necessidades de QoS, pelo menos na Internet pública. O Skype, por exemplo, tem sido muito bem- 
-sucedido, em parte porque seu serviço gratuito torna as pessoas mais dispostas a tolerar a falta de 
garantias de QoS. De um ponto de vista da tecnologia, uma combinação de taxa adaptativa (o Skype tem 
um codec de voz com taxa de bits variável) e roteamento overlay (uma técnica discutida no Capítulo 9) 
demonstraram ser bastante eficazes na entrega de uma qualidade decente à aplicação, apesar da falta 
de ajuda da rede. Ao mesmo tempo, em ambientes corporativos onde os usuários são mais exigentes, 
o suporte a QoSno nível de rede continua a ver implantação e sofisticação cada vez maiores. 


Leitura adicional 


A lista de leitura recomendada para este capítulo é longa, refletindo a amplitude do trabalho interessante que está sendo 

feito na área de controle de congestionamento e alocação de recursos. Ela inclui os artigos originais que introduzem os 

diversos mecanismos discutidos neste capítulo. Além de uma descrição mais detalhada desses mecanismos, contendo 

uma análise completa de sua eficácia e justiça, esses artigos são leitura essencial em razão das ideias que eles dão quanto 

à interação de diversos aspectos relacionados ao controle de congestionamento. Além disso, o primeiro artigo oferece 

uma excelente comparação geral entre alguns dos primeiros trabalhos sobre o assunto, enquanto o último é considerado 

um dos artigos originais no desenvolvimento de capacidades de QoS na Internet. 

Gerla, M.;Kleinrock, L. Flow control: a comparative survey. IEEE Transactions on Communications COM, v. 28, n. 4, p. 
553-73, abril de1980. 

Demers, A.; Keshav, S.;Shenker, S. Analysis and simulation of a fair queuing algorithm. Proceedings of the SIGCOMM 
89Symposium, p. 1-12, setembro de 1989. 

Jacobson, V. Congestion avoidance and control. Proceedings of theSIGCOMM '88 Symposium, p. 314-29, agosto de 1988. 

Floyd, S.; Jacobson, V. Random early detection gateways for congestion avoidance. IEEE/ACM Transactions on Networking, 
v. 1, n. 4, p. 397-413, agosto de 1993. 

Clark, D.; Shenker, S.; Zhang, L. Supporting real-time applications in an integrated services packet network: architecture 
and mechanism. Proceedings of the SIGCOMM '92 Symposium, p. 14-26, agosto de 1992. 

Parekh, A.; Gallager, R. A generalized processor sharing approach to flow control in integrated services networks: The 
multiple node case. IEEE/ACM Transactions on Networking, v. 2, n. 2, p. 137-50, abril de 1994. 
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Além desses artigos recomendados, existe uma grande variedade de outros materiais valiosos sobre 
alocação de recursos. Para iniciantes, dois artigos iniciais de Kleinrock [Kle79] e Jaffe [Jaf81] definem a 
base para o uso da potência como medida da eficácia no controle de congestionamento. Além disso, Jain 
[Jai91] fornece uma discussão profunda de diversas questões relacionadas à avaliação de desempenho, 
incluindo uma descrição do índice de justiça de Jain. 

Mais detalhes sobre o TCP Vegas podem ser encontrados em Brakmo e Peterson [BP95], com um trabalho 
que dá sequência a ele sendo apresentado em Low et al. [LPWO02b]. Melhorias nos algoritmos de controle 
de congestionamento do TCP continuam a ser exploradas. O FAST TCP estende o TCP Vegas com cenários 
de alto produto atraso largura de banda [WJLHO6]. O CUBIC, a variante TCP agora encontrada no Linux, é 
descrito por Ha et al. [HRX08]. Floyd [Flo03] descreve a especificação do HighSpeed TCP um padrão experi- 
mental da IETE Técnicas semelhantes de prevenção de congestionamento introduzidas na Seção 6.4 podem 
ser encontradas em Wang e Crowcroft [WC92, WC91] e Jain [Jai89], com o primeiro artigo dando uma visão 
geral especialmente boa sobre a prevenção de congestionamento, com base em um entendimento comum 
de como a rede muda quando se aproxima do congestionamento. Alguns problemas e as modificações 
propostas para o algoritmo RED, incluindo Flow RED (FRED) são descritos por Lin et al. [LM97]. 

O padrão proposto do ECN é descrito por Ramakrishnan, Floyd e Black em [RFBO1]. Os esforços 
para generalizar essa ideia na forma de gerenciamento de fila ativo foram publicados por Stoica et 
al. [SSZ98], Low et al. [LPW +*+ 02a ] e Katabi et al. [KHRO2]. O artigo de Katabi introduz o XCP, um dos 
novos protocolos de transporte propostos, que trata da questão de melhorar a vazão do TCP em redes 
com elevado produto atraso xlargura de banda. 

Existe um trabalho considerável sobre escalonamento de pacotes, que estendeu os trabalhos originais 
sobre enfileiramento justo e compartilhamento de processador, citados anteriormente. Alguns exem- 
plos excelentes incluem os artigos de Stoica e Zhang [SZ97], Bennett e Zhang [BZ96], e Goyal, Vin e 
Chen [GVC96]. 

Muitos artigos adicionais foram publicados sobre a arquitetura de Serviços Integrados, incluindo 
uma visão geral de Braden et al. [BCS94] e uma descrição do RSVP por Zhang et al. [ZDE+93]. O 
primeiro artigo a focalizar o assunto de Serviços Diferenciados é o de Clark [Cla97], que introduz o 
mecanismo RIO e também a arquitetura geral dos Serviços Diferenciados. Um trabalho subsequente 
de Clark e Fang [CF98] apresenta os resultados de algumas simulações. Blake et al. [BBC*+98] define a 
arquitetura de Serviços Diferenciados, enquanto Davie et al. [DCB+02] define o comportamento por 
salto do EF Para ver como as aplicações de tempo real se saem quando tentam operar de modo confiável 
usando o serviço de melhor esforço da Internet, recomendamos o artigo sobre satisfação do usuário 
do Skype de Chen et al. [(CHHLO6]. 

Finalmente, além do trabalho descrito anteriormente sobre a melhoria do TCP para aplicações de 
dados tradicionais, vários algoritmos de controle de congestionamento amigáveis a TCP foram recen- 
temente propostos e adaptados para uso por aplicações de tempo real. Entre estes estão algoritmos de 
Floyd et al. [FHPW00], Sisalem e Schulzrinne [SS98], Rhee et al. [ROY00] e Rejaie et al. [RHE99)]. Esses 
algoritmos foram fundamentados no modelo inicial baseado em equação para a vazão do TCP de Padhye 
etal. [PFTK98]. Um protocolo de controle de taxa de transferência amigável a TCP foi especificado pela 
IETF [HFPW083], e a ideia de incluir controle de congestionamento no UDP levou ao Protocolo de Con- 
trole de Congestionamento de Datagramas (DCCP - Datagram Congestion Control Protocol) [KHF06]. 


Exercícios 


1. É possível definir fluxos tomando como base uma comunicação host a host ou processo a processo. 

a. Discuta as implicações de cada abordgem para os programas de aplicação. 

b. O IPv6 inclui um campo RótuloFluxo, para fornecer dicas aos roteadores relativas a fluxos 
individuais. O host de origem deve colocar aqui um hash pseudoaleatório de todos os outros 
campos que sirvam para identificar o fluxo; desse modo, o roteador pode usar qualquer 
subconjunto desses bits como valor de hash para uma busca rápida do fluxo. Em que 
exatamente deve ser baseado o RótuloFluxo, para cada uma dessas duas técnicas? 
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10. 


O TCP utiliza um modelo de alocação de recursos centrado no host, baseado em feedback e baseado 
em janelas. Como o TCP poderia ter sido projetado para usar os seguintes modelos ao invés disso? 
a. Centrado no host, baseado em feedback e baseado em taxa. 

b. Centrado no roteador e baseado em feedback. 


. Desenhe curvas para vazão, atraso e potência, cada uma como uma função da carga, para uma 


rede Ethernet conforme descrita no Exercício 51 do Capítulo 2. O tamanho médio do pacote é 
de 5 slots de tempo, e quando N estações estão tentando transmitir, o atraso médio até que uma 
estação tenha sucesso é N/2 slots de tempo. A vazão deve ser medida como uma porcentagem 
do valor máximo. A carga deve ser medida (de modo pouco natural) como o número de estações 
(N) prontas para transmitir a qualquer momento; observe que isso implica que existe sempre 
(exceto no caso em que N=0, que você pode ignorar) uma estação pronta para transmitir. 
Considere que cada estação possui apenas um pacote para transmitir de cada vez. 
Suponha que dois hosts A e B estejam conectados por meio de um roteador R. O enlace A-R 
possui largura de banda infinita; o enlace R-B pode enviar um pacote por segundo. A fila de R é 
infinita. A carga deve ser medida como o número de pacotes por segundo enviados de A para B. 
Desenhe os gráficos de vazão versus carga e atraso versus carga, ou, se um gráfico não puder ser 
desenhado, explique por quê. Haveria outra maneira mais apropriada de medir a carga? 
É possível que o TCP Reno alcance um estado com o tamanho da janela de congestionamento 
muito maior do que (por exemplo, o dobro de) RTT x largura de banda? Isso é provável? 
Considere o arranjo de hosts H e roteadores R e RI na Figura 6.27. Todos os enlaces são 
full-duplex, e todos os roteadores são mais rápidos do que seus enlaces. Mostre que não 
é possível que RI fique congestionado e que, para qualquer outro roteador R, podemos encontrar 
um padrão de tráfego que congestione apenas esse roteador. 
Suponha que um esquema de controle de congestionamento resulte em uma coleção de fluxos 
competindo e que ele atingem as seguintes taxas de vazão: 200 KBps, 160 KBps, 110 KBps, 
95 KBps e 150 KBps. 
a. Calcule o índice de justiça para esse esquema. 
b. Agora acrescente um fluxo com uma taxa de vazão de 1.000 KBps ao cenário descrito, 

e recalcule o índice de justiça. 
No enfileiramento justo, o valor F; foi interpretado como um carimbo de tempo: o momento 
em que o i-ésimo pacote terminaria de ser transmitido. Dê uma interpretação para F; no 
enfileiramento justo ponderado, e também dê uma fórmula para ele em termos de F,.,, 
do instante de chegada A, do tamanho do pacote F; e do peso p atribuído ao fluxo. 
Dê um exemplo de como o fato de um pacote não se apropriar do lugar na fila de outro pacote, 
na implementação do enfileiramento justo, leva a uma ordem de transmissão de pacotes 
diferente do serviço de rodízio bit a bit. 
Suponha que um roteador tenha três fluxos de entrada e um de saída. Ele recebe os pacotes 
listados na Tabela 6.1 praticamente ao mesmo tempo, na ordem listada, durante um período 
em que a porta de saída está ocupada, mas todas as filas estão vazias. Forneça a ordem 
em que os pacotes são transmitidos, considerando: 
a. enfileiramento justo 
b. enfileiramento justo ponderado, com o fluxo 2 tendo peso 2 e os outros dois com peso 1 


R1 









Largura de banda do enlace de 4 MBps 
Largura de banda do enlace de 2 MBps 
R 
Largura de banda do enlace de 1MBps 
H H H H H H H 


H 


FIGURA 6.27 Diagrama para o Exercício 6. 
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Tabela 6.1 Pacotes para o Exercício 10 


Pacote Tamanho Fluxo 





o JOW swNa 


100 1 
100 
100 
100 
190 
200 
110 

50 


w WwW NN aaa 


Tabela 6.2 Pacotes para o Exercício 11 





Pacote Tamanho Fluxo 
1 200 1 
2 200 1 
3 160 2 
4 120 2 
5 160 2 
6 210 3 
7 150 3 
8 90 3 
* 11. Suponha que um roteador tenha três fluxos de entrada e um de saída. Ele recebe os pacotes 


12. 


13. 


listados na Tabela 6.2 praticamente ao mesmo tempo, na ordem listada, durante um período em 

que a porta de saída está ocupada, mas todas as filas estão vazias. Forneça a ordem em que os 

pacotes são transmitidos, considerando 

a. enfileiramento justo 

b. enfileiramento justo ponderado, com o fluxo 2 tendo o dobro da fatia do fluxo 1, e o fluxo 3 
tendo 1,5 vez a fatia do fluxo 1. Observe que empates devem ser resolvidos nesta ordem de 
prioridade: fluxo 1, fluxo 2, fluxo 3. 

Suponha que a política de descarte de um roteador seja descartar o pacote de maior custo 

sempre que as filas estão cheias, onde o “custo” de um pacote é definido pelo roteador como o 

produto de seu tamanho pelo tempo restante que ele passará na fila. (Observe que, no cálculo 

do custo, é equivalente usar a soma dos tamanhos dos pacotes anteriores no lugar do tempo 

restante.) 

a. Que vantagens e desvantagens essa política poderia oferecer, comparada com o descarte da 
cauda? 

b. Dê um exemplo de uma sequência de pacotes enfileirados para os quais o descarte do pacote 
de maior custo difere do descarte do maior pacote. 

c. Dê um exemplo em que dois pacotes trocam a ordem de seus custos relativos (ou seja, o que 
era maior torna-se o menor e vice-versa) com o passar do tempo. 

Dois usuários, um usando Telnet e um enviando arquivos com FTP enviam seu tráfego por meio 

do roteador R. O enlace de saída de R é lento o suficiente para que os dois usuários mantenham 

pacotes na fila de R o tempo todo. Discuta o desempenho relativo percebido pelo usuário Telnet 

se a política de enfileiramento de R para esses dois fluxos for 

a. serviço de rodízio 

b. enfileiramento justo 

c. enfileiramento justo modificado, onde contamos o custo apenas dos bytes de dados, e não 
dos cabeçalhos IP ou TCP 

Considere apenas o tráfego de saída. Suponha que os pacotes Telnet tenham 1 byte de dados, 

que os pacotes FTP tenham 512 bytes de dados e que todos os pacotes tenham 40 bytes de 

cabeçalho. 
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14. 


“15. 


16. 


17. 


18. 


Considere um roteador que esteja gerenciando três fluxos, nos quais pacotes de tamanho 
constante cheguem nos seguintes instantes absolutos: 

Fluxo A: 1, 2, 4,6,7,9, 10 

Fluxo B: 2, 6, 8, 11, 12, 15 

Fluxo C: 1, 2, 3, 5,6,7,8 

Todos os três fluxos compartilham o mesmo enlace de saída, pelo qual o roteador pode 

transmitir um pacote por unidade de tempo. Considere que existe uma quantidade infinita de 

espaço no buffer. 

a. Suponha que o roteador implemente o enfileiramento justo. Para cada pacote, determine 
o instante em que ele é transmitido pelo roteador. Os empates na hora da chegada são 
resolvidos na ordem A, B, C. Observe que a hora absoluta T=2 corresponde à hora do relógio 
FQ A;=1,5. 

b. Suponha que o roteador implemente o enfileiramento justo ponderado, no qual os fluxos A e 
B recebem uma fatia igual da capacidade e o fluxo C recebe o dobro da capacidade do fluxo A. 
Para cada pacote, determine o instante em que ele é transmitido. 

Considere um roteador que esteja gerenciando três fluxos, nos quais pacotes de tamanho 

constante chegam nos seguintes instantes absolutos: 

Fluxo A: 1, 3, 5,6,8,9, 11 
Fluxo B: 1, 4, 7, 8, 9, 13, 15 
Fluxo C: 1, 2, 4, 6,7, 12 

Todos os três fluxos compartilham o mesmo enlace de saída, pelo qual o roteador pode 

transmitir um pacote por unidade de tempo. Considere que existe uma quantidade infinita de 

espaço no buffer. 

a. Suponha que o roteador implemente o enfileiramento justo. Para cada pacote, determine 
o instante em que ele é transmitido pelo roteador. Os empates na hora da chegada são 
resolvidos na ordem A, B, C. Observe que a hora absoluta T=2 corresponde à hora do relógio 
FQA,=1,333. 

b. Suponha que o roteador implemente o enfileiramento justo ponderado, no qual os fluxos A e 
C recebem uma fatia igual da capacidade e o fluxo B recebe o dobro da capacidade do fluxo A. 
Para cada pacote, determine o instante em que ele é transmitido. 

Considere que o TCP implementa uma extensão que de suporte a tamanhos de janela muito 

maiores do que 64 KB. Suponha que você esteja usando esse TCP estendido por um enlace 

de 1 Gbps com uma latência de 100 ms para transferir um arquivo de 10 MB, e que a janela 

de recepção do TCP é de 1 MB. Se o TCP envia pacotes de 1 KB (supondo que não haja 

congestionamento nem pacotes perdidos): 

a. Quantos RTTs são necessários até que a partida lenta abra a janela de envio até 1 MB? 

b. Quantos RTTs são necessários para enviar o arquivo? 

c. Seo tempo para enviar o arquivo for dado pelo número de RTTs necessários multiplicado 
pela latência do enlace, qual é a vazão efetiva para a transferência? Que porcentagem da 
largura de banda do enlace é utilizada? 

Considere um algoritmo de controle de congestionamento simples, que utiliza aumento linear 

e diminuição multiplicativa mas não a partida lenta, que funciona em unidades de pacotes 

ao invés de bytes, e que inicia cada conexão com uma janela de congestionamento igual a 

um pacote. Esboce esse algoritmo em detalhes. Considere que o atraso corresponda apenas à 

latência e que, quando um grupo de pacotes é enviado, somente um único ACK é retornado. 

Desenhe a janela de congestionamento como uma função dos tempos de ida e volta para a 

situação em que os pacotes a seguir são perdidos: 9, 25, 30, 38 e 50. Para simplificar, considere 

um mecanismo de expiração do tempo limite perfeito, que detecta um pacote perdido 
exatamente 1 RTT após ser transmitido. 

Para a situação dada no problema anterior, calcule a vazão efetiva alcançada por essa conexão. 

Considere que cada pacote mantém 1 KB de dados e que o RTT =100 ms. 
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19. Durante o aumento linear, o TCP calcula um incremento na janela de congestionamento como 
Incremento= MSS x (MSS/JanelaCongestionamento) 


Explique por que o cálculo desse incremento, toda vez que um ACK chega, pode não resultar 
no incremento correto. Forneça uma definição mais precisa para esse incremento. (Dica: Um 
certoACK pode confirmar mais ou menos do que um MSS de dados.) 

20. Sob quais circunstâncias os eventos esparsos de expiração do tempo limiteainda poderão 
ocorrer no TCP mesmo quando o mecanismo de retransmissão rápida estiver sendo usado? 

21. Suponha que entre A e B exista um roteador R. A largura de banda A-R é infinita (ou seja, os 
pacotes não são atrasados), mas o enlace R-B introduz um atraso de transmissão de 1 pacote 
por segundo devido a sua largura de banda limitada (ou seja, 2 pacotes levam 2 segundos etc.). 
As confirmações de B para R, no entanto, são enviadas instantaneamente. A envia dados para B 
por uma conexão TCP usando o mecanismo de partida lenta, mas com um tamanho de janela 
arbitrariamente grande. R tem um tamanho de fila igual a 1, além do pacote que está sendo 
transmitido. A cada segundo, o transmissor primeiro processa quaisquer ACKs que chegam e 
depois responde a quaisquer eventos de expiração de tempo limite. 

a. Considerando um período de TempoExpiração fixo de 2 segundos, o que é enviado e recebido 
para T=0, 1, ..., 6 segundos? O enlace fica ocioso devido a eventos de expiração de tempo 
limite? 

b. O que mudaria se TempoExpiração fosse 3 segundos? 

22. Suponha que A, R e B sejam iguais aos do exercício anterior, exceto que a fila de R agora tem um 
tamanho de três pacotes, além do que está sendo transmitido. A inicia uma conexão usando 
a partida lenta, com uma janela de recepção de tamanho infinito. A retransmissão rápida é 
feita no segundo ACK duplicado (ou seja, o terceiro ACK pedindo o mesmo pacote); o valor de 
TempoExpiração é infinito. Ignore a recuperação rápida; quando um pacote é perdido, suponha 
que o tamanho da janela seja ajustado para 1. Crie uma tabela mostrando, para os primeiros 15 
segundos, o que A recebe, o que A transmite, o que R transmite, a fila de Re o que R descarta. 

23. Suponha que o enlace R-B do exercício anterior mude de um atraso de transmissão devido a 
uma largura de banda limitada para um atraso de propagação, de modo que dois pacotes agora 
levam 1 segundo para serem enviados. Liste o que é enviado e recebido durante os primeiros 
8 segundos. Considere um valor de tempo limite estático de 2 segundos, que a partida lenta é 
usada quando o tempo limite expira e que os ACKs são enviados aproximadamente ao mesmo 
tempo em que são consolidados. Observe que o tamanho de fila de R agora é irrelevante (por 
quê?). 

24. Suponha que o host A alcance o host B através dos roteadores RI e R2: A-RI-R2-B. A 
retransmissão rápida não é utilizada e A calcula TempoExpiração como 2 x RTTEstimado. 
Considere que os enlaces A-Rle R2-B possuem largura de banda infinita; o enlace RI>R2, 
porém, introduz um atraso de transmissão de 1 segundo por pacote para os pacotes de dados 
(embora não para ACKs) devido a uma de largura de banda limitada. Descreva um cenário em 
que o enlace R1-R2 não é 100% utilizado, embora A sempre tenha dados prontos para serem 
enviados. (Dica: Suponha que o valor de JanelaCongestionamento de A aumente de N para N+1, 
onde N é o tamanho da fila de R1.) 

25. Você é um provedor de serviços da Internet; os hosts de seus clientes se conectam diretamente 
aos seus roteadores. Você sabe que alguns hosts estão usando TCPs experimentais e suspeita 
que alguns possam estar usando um TCP “insaciável”, sem controle de congestionamento. Que 
medições você poderia fazer no seu roteador para verificar que um cliente não esteve usando 
partida lenta alguma? Se um cliente usasse partida lenta na inicialização, mas não após um 
evento de expiração do tempo limite, você conseguiria detectar isso? 

26. Burlar os mecanismos de controle de congestionamento do TCP normalmente exige a 
cooperação explícita do emissor. Porém, considere o lado receptor de uma transferência 
de dados grandes usando um TCP modificado para confirmar (enviar ACKs para) pacotes 
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27. 


28. 


29. 


30. 


31. 


que ainda não chegaram. Ele pode fazer isso ou porque nem todos os dados são necessários ou 

porque os dados que se perderam podem ser recuperados em uma transferência separada mais 

tarde. Que efeito o comportamento desse receptor tem sobre as propriedades de controle de 

congestionamento da sessão? Você poderia idealizar um meio de modificar o TCP para evitar a 

possibilidade de se tirar proveito dos emissores dessa maneira? 

Considere o gráfico do TCP mostrado na Figura 6.28. Identifique os intervalos de tempo 

representando a partida lenta na inicialização, a partida lenta após o evento de expiração de 

tempo limite e a prevenção de congestionamento via aumento linear. Explique o que está 
acontecendo desde T=0,5 até T= 1,9. A versão do TCP que gerou esse acompanhamento inclui 
um recurso ausente no TCP que gerou a Figura 6.11. Qual é esse recurso? Este acompanhamento 

e o da Figura 6.13 não possuem um recurso. Qual é esse recurso? 

Suponha que você esteja fazendo o download de um arquivo grande por um enlace telefônico 

de 3 KBps. Seu software exibe um contador da média de bytes por segundo. Como o controle de 

congestionamento do TOP e perdas de pacote ocasionais fazem esse contador flutuar? Considere 
que, digamos, somente um terçodo RTT total seja gasto no enlace telefônico. 

Suponha que o TCP seja usado por um enlace com perdas, que perde em média um segmento 

a cada quatro. Considere que o tamanho da janela de atraso x largura de banda seja 

consideravelmente maior do que quatro segmentos. 

a. O que acontece quando iniciamos uma conexão? Chegamos alguma vez à fase de aumento 
linear do algoritmo de prevenção de congestionamento? 

b. Sem usar um mecanismo de feedback explícito dos roteadores, o TCP teria alguma maneira 
de distinguir tais perdas de enlace das perdas de congestionamento, pelo menos a curto 
prazo? 

c. Suponha que os emissores TCP obtivessem indicações de congestionamento confiáveis 
dos roteadores. Considerando que enlaces como os indicados anteriormente fossem 
compartilhados, seria viável admitir tamanhos de janela muito maiores do que quatro 
segmentos? O que o TCP teria que fazer? 

Suponha que duas conexões TCP compartilhem um caminho que passa pelo roteador R. 

O tamanho da fila do roteador é de seis segmentos; cada conexão possui uma janela de 

congestionamento estável de três segmentos. Nenhum controle de congestionamento é usado 

por essas conexões. Uma terceira conexão TCP agora é tentada, também passando por R. A 

terceira conexão não usa controle de congestionamento algum. Descreva um cenário em que, 

pelo menos por um tempo, a terceira conexão não recebe a largura de banda disponível, e 

as duas primeiras conexões continuam com 50% da largura de banda cada. Importa alguma 

coisa se a terceira conexão usa a partida lenta? Como o mecanismo completo de prevenção de 

congestionamento por parte das duas primeiras conexões ajuda a solucionar isso? 

Suponha que uma conexão TCP tenha um tamanho de janela de congestionamento de oito 

segmentos, um RTT de 800 ms, que o emissor envia segmentos a uma taxa regular de um a 

cada 100 ms, e que o receptor envia ACKs de volta na mesma taxa, sem atraso. Um segmento 

é perdido, e a perda é detectada pelo algoritmo de retransmissão rápida no recebimento do 

terceiro ACK duplicado. No momento em que o ACK do segmento retransmitido finalmente 

chega, quanto tempo total o emissor perdeu (em comparação com a transmissão sem perdas) se: 
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FIGURA 6.28 Gráfico do TCP para o Exercício 27. 
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a. o emissor espera o ACK do pacote perdido e retransmitido antes de deslizar novamente a 
janela para a direita? 

b. o emissor usa a chegada repetida de cada ACK duplicado como uma indicação de que ele 
pode deslizar a janela um segmento para a direita? 

O texto afirma que o aumento aditivo é uma condição necessária para um mecanismo de 

controle de congestionamento ser estável. Esboce uma instabilidade específica que poderia 

surgir se todos os aumentos fossem exponenciais; ou seja, se o TCP continuasse a usar a partida 

lenta depois que a JanelaCongestionamento aumentasse além do LimiarCongestionamento. 

Discuta as vantagens e desvantagens relativas de marcar um pacote (como no mecanismo 

DECbit) versus descartar um pacote (como nos gateways RED que não implementam ECN). 

Considere um gateway RED com MaxP =0,01 e com um tamanho de fila médio a meio caminho 

entre os dois limiares. 

a. Encontre a probabilidade de descarte Pon para cont=1 e cont= 100. 

b. Calcule a probabilidade de que nenhum dos primeiros 50 pacotes seja descartado. Observe 
queissoé(1-P)x..x (1 — P50). 


. Considere um gateway RED com MaxP =p, com um tamanho de fila médio a meio caminho entre 


Ê 41. 


42. 


43. 


os dois limiares. 

a. Calcule a probabilidade de que nenhum dos primeiros n pacotes sejam descartados. 

b. Encontre p tal que a probabilidade de que nenhum dos primeiros n pacotes sejam 
descartados é a. 

Explique a intuição por trás da definição de LimiarMáximo=2 x LimiarMínimo nos gateways 

RED. 

Nos gateways RED, explique por que o LimiarMáximo é na realidade menor que o tamanho real 

do conjunto de buffers disponível. 

Explique o conflito fundamental entre tolerar tráfegoem rajadas e controlar o congestionamento 

da rede. 

Em sua opinião, por que a probabilidade de descarte P de um gateway RED não aumenta 

simplesmente de forma linear de P=0 no LimiarMínimo até P= 1 no LimiarMáximo? 

A notificação explícita de congestionamento (ECN), conforme definida no RFC 3168, exige um 

bit para indicar se as extremidades são capazes de usar ECN. Qual seria a desvantagem de não 

ter esse bit? 

No TCP Vegas, o cálculo de TaxaReal é feito dividindo-se a quantidade de dados transmitidos em 

um intervalo de RTT pelo tamanho do RTT. 

a. Mostre que, para qualquer conexão TCP se o tamanho da janela permanecer constante, então 
a quantidade de dados transmitidos em um intervalo de RTT é constante quando uma janela 
completa é enviada. Considere que o emissor transmita cada segmento instantaneamente ao 
receber um ACK, os pacotes não são perdidos e são entregues na ordem, os segmentos são 
todos do mesmo tamanho e o primeiro enlace ao longo do caminho não é o mais lento. 

b. Faça um esboço de linha de tempo mostrando que a quantidade de dados por RTT acima 
pode ser menor que JanelaCongestionamento. 

Suponha que uma conexão TCP Vegas meça o RTT do seu primeiro pacote e definao RTTBásico 

com esse valor, mas depois ocorre uma falha no enlace da rede e todo o tráfego subsequente é 

roteado através de um caminho alternativo, com o dobro do RTT. Como o TCP Vegas responderá 

a isto? O que acontecerá com o valor de JanelaCongestionamento? Considere que não ocorrem de 

fato eventos de expiração do tempo limite, e que £ seja muito menor que a TaxaEsperada inicial. 

Considere as duas causas a seguir de um atraso de rede de 1 segundo (considere que os ACKs 

retornam instantaneamente): 

Um roteador intermediário com um atraso de transmissão de 1 segundo por pacote devido à 
largura de banda limitada na saída e nenhum tráfego concorrente 

Um roteador intermediário com um atraso de transmissão de 100 ms por pacote devido à 
na largura de banda limitada na saída e com sua fila constantemente reabastecida com dez 
pacotes (provenientes de outra origem) 
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44. 


45. 


46. 


47. 


A 48. 


49. 


a. Como um protocolo de transporte poderia distinguir em geral entre esses dois casos? 

b. Suponha que o TCP Vegas transmita dados pelas conexões acima, com um 
valor deJanelaCongestionamento inicial de três pacotes. O que acontecerá com 
JanelaCongestionamento em cada caso? Considere que RTTBásico= 1 segundo e que f é 
um pacote por segundo. 

Muitas aplicações de vídeo em tempo real são executadas sobre UDP ao invés de TCP pois não 

podem tolerar atrasos de retransmissão. Porém, isso significa que as aplicações de vídeo não são 

limitadas pelo algoritmo de controle de congestionamento do TCP Que impacto isso tem sobre o 

tráfego TCP? Seja específico sobre as consequências. 

Felizmente, essas aplicações de vídeo normalmente utilizam RTP (Seção 5.4), o que resulta em 

relatórios de receptor RTCP sendo enviados do destino de volta à origem. Esses relatórios são 

enviados periodicamente (por exemplo, uma vez por segundo) e incluem a porcentagem de 
pacotes recebidos com sucesso no último período de relatório. Descreva como a origem poderia 
usar essa informação para ajustar sua taxa de uma maneira compatível com o TCP. 

Forneça um argumento pelo qual o problema de controle de congestionamento é mais bem 

gerenciado no nível de inter-rede do que no nível ATM, pelo menos quando apenas parte da 

inter-rede é ATM. Em uma rede exclusivamente IPsobreATM, o congestionamento é mais bem 
gerenciado no nível de célula ou no nível do TCP? Por quê? 

Considere a taxonomia da Figura 6.23. 

a. Dê um exemplo de uma aplicação de tempo real que seja intolerante/adaptável à taxa. 

b. Explique por que você poderia esperar que uma aplicação tolerante a perdas fosse pelo 
menos um pouco adaptável à taxa. 

c. Apesar do item (b), dê um exemplo de uma aplicação que poderia ser considerada tolerante/ 
não adaptável. (Dica: Tolerar até mesmo pequenas perdas qualifica uma aplicação como 
tolerante a perdas; você precisará interpretar a adaptabilidade à taxa como a capacidade de 
ajustar-se a mudanças substanciais na largura de banda.) 

O escalonamento de transmissão (Tabela 6.3) para determinado fluxo lista, para cada segundo, 

o número de pacotes enviados entre esse instante e o segundo seguinte. O fluxo precisa 

permanecer dentro dos limites de um filtro de balde de fichas. De que profundidade de balde 

o fluxo precisa para as seguintes taxas de fichas? Considere que o balde está inicialmente cheio. 

a. 2 pacotes por segundo 

b. 4 pacotes por segundo 

O escalonamento de transmissão (Tabela 6.4) para determinado fluxo lista, para cada segundo, 

o número de pacotes enviados entre esse instante e o segundo seguinte. O fluxo precisa 

permanecer dentro dos limites de um filtro de balde de fichas. Determine a profundidade do 

balde B necessária como uma função da taxa de fichas r. Observe que rutiliza apenas valores 
inteiros positivos. Considere que o balde esteja inicialmente cheio. 

Suponha que um roteador tenha aceito fluxos com as TSpecs mostradas na Tabela 6.5, descrita 

em termos de filtros de balde de fichas com uma taxa de fichas de t pacotes por segundo 

e profundidade de balde de B pacotes. Todos os fluxos estão na mesma direção e o roteador pode 

encaminhar um pacote a cada 0,1 segundo. 


Tabela 6.3 Escalonamento de transmissão para o Exercício 47 


Tempo (segundos) Pacotes enviados 
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Tabela 6.4 Escalonamento de transmissão para o Exercício 48 





Tempo (segundos) Pacotes enviados 
0 5 
1 5 
2 1 
3 0 
4 6 
5 1 


Tabela 6.5 TSpecs para o Exercício 49 
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a. Qual é o atraso máximo que um pacote poderia sofrer? 

b. Qual é o número mínimo de pacotes do terceiro fluxo que o roteador enviaria por 2,0 
segundos, supondo que o fluxo envie pacotes em sua taxa máxima uniformemente? 

50. Suponha que um roteador RSVP de repente perca a informação sobre seu estado de reserva, mas 

apesar disso continue funcionando: 

a. O que acontecerá com os fluxos reservados existentes se o roteador tratar fluxos reservados e 
não reservados por meio de uma única fila FIFO? 

b. O que poderia acontecer com os fluxos reservados existentes se o roteador usasse o 
enfileiramento justo ponderado para separar o tráfego reservado e não reservado? 

c. Em algum momento, os receptores nesses fluxos solicitarão que suas reservas sejam 
renovadas. Mostre um cenário em que essas solicitações são negadas. 


Dados fim a fim 


É um erro capital expor teorias antes que se tenham dados. 
Sir Arthur Conan Doyle 


E E Problema: o que fazemos com os dados? E 


Do ponto de vista da rede, os programas de aplicação enviam mensagens uns aos outros. Cada 
uma dessas mensagens é apenas uma sequência de bytes não interpretados. Entretanto, do ponto 
de vista da aplicação, essas mensagens contêm vários tipos de dados - vetores de inteiros, 
quadros de vídeo, linhas de texto, imagens digitais e assim por diante. Em outras palavras, esses 
bytes possuem significado. Agora, vamos considerar o problema de como codificar melhor 

os diferentes tipos de dados que os programas de aplicação desejam trocar, transformando-os 
em sequências de bytes. Em muitos aspectos, isso é semelhante ao problema da codificação 

de sequências de bytes em sinais eletromagnéticos, que vimos na Seção 2.2. 

Retornando à nossa discussão sobre codificação no Capítulo 2, havia essencialmente duas 
preocupações. A primeira era que o receptor fosse capaz de extrair a mesma mensagem do 

sinal que o transmissor enviou; esse era o problema do enquadramento. A segunda era tornar a 
codificação o mais eficiente possível. Essas duas preocupações estão presentes quando os dados 
da aplicação são codificados em mensagens da rede. 

Para que o receptor extraia a mensagem enviada pelo transmissor, os dois lados precisam entrar 
em acordo sobre um formato de mensagem, normalmente chamado formato de apresentação. 

Se o emissor quiser enviar ao receptor um vetor de inteiros, por exemplo, então os dois lados 
terão que entrar em acordo sobre a aparência de cada inteiro (qual o seu tamanho e se o bit mais 
significativo vem primeiro ou por último) e quantos elementos existem no vetor. A Seção 7.1 
descreve diversas codificações de dados computacionais tradicionais, como inteiros, números 

de ponto flutuante, cadeias de caracteres, vetores e estruturas. Também existem formatos 

bem estabelecidos para dados multimídia: o vídeo, por exemplo, normalmente é transmitido 

no formato MPEG (Moving Picture Experts Group), e as imagens paradas normalmente são 
transmitidas no formato JPEG (Joint Photographic Experts Group) ou GIF (Graphical Interchange 
Format). As questões particulares relativas à codificação de dados multimídia são discutidas na 
Seção 7.2. 

Tipos de dados multimídia exigem que pensemos a respeito da apresentação e da compressão. 

Os formatos bem conhecidos para a transmissão e armazenamento de áudio e vídeo lidam com 
essas duas questões: garantir que o que foi gravado, fotografado ou ouvido no emissor possa ser 
interpretado corretamente pelo receptor, e fazer isso de um modo que não sobrecarregue a rede 
com quantidades maciças de dados multimídia. 

A compressão e, de um modo mais geral, a eficiência da codificação, possuem uma história rica, 
tendo início no trabalho pioneiro de Shannon sobre a teoria da informação na década de 1940. 
Com efeito, existem duas forças opostas em ação aqui. Em uma direção, você gostaria do máximo 
de redundância possível nos dados, de modo que o receptor seja capaz de extrair os dados 
corretos mesmo que erros sejam introduzidos na mensagem. Os códigos de detecção e correção 
de erros que vimos na Seção 2.4 acrescentam informações redundantes às mensagens exatamente 
para essa finalidade. Na outra direção, gostaríamos de remover o máximo de redundância possível 
dos dados, para podermos codificá-los com o mínimo de bits possível. Acontece que os dados 
multimídia oferecem diversas oportunidades para compressão, devido ao modo como nossos 
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sentidos e cérebros processam sinais visuais e auditivos. Não escutamos altas frequências tão 
bem quanto as mais baixas, e não observamos detalhes pequenos tão bem quanto os elementos 
maiores em uma imagem, especialmente se a imagem estiver se movendo. 

A compressão é importante para os projetistas de redes por diversos motivos, não apenas 

porque raramente obtemos uma abundância de largura de banda em todas as partes da rede. 

Por exemplo, o modo como projetamos um algoritmo de compressão afeta nossa sensibilidade a 
dados perdidos ou atrasados, e com isso pode influenciar o projeto dos mecanismos de alocação 
de recursos e os protocolos fim a fim. Por outro lado, se a rede subjacente for incapaz de garantir 
uma quantidade fixa de largura de banda pela duração de uma videoconferência, podemos 
decidir projetar algoritmos de compressão que possam se adaptar a condições variáveis na rede. 
Finalmente, um aspecto importante tanto da formatação de apresentação quanto da compressão 
dos dados é que elas exigem que os hosts emissor e receptor processem cada byte de dados na 
mensagem. É por esse motivo que a formatação da apresentação e a compressão às vezes são 
chamadas de funções de manipulação de dados. Isso contrasta com a maioria dos protocolos que 
vimos até este ponto, que processam uma mensagem sem examinar seu conteúdo. Devido a essa 
necessidade de ler, computar e escrever cada byte de dados em uma mensagem, as manipulações 
de dados afetam a vazão fim a fim ao longo da rede. De fato, essas manipulações podem ser o fator 
limitador. 


7.1 Formatação de apresentação 


Uma das transformações mais comuns dos dados da rede é da representação usada pelo programa de 
aplicação para um formato adequado para a transmissão por uma rede e vice-versa. Essa transformação 
normalmente é chamada formatação de apresentação. Conforme ilustrado na Figura 7.1, o programa 
emissor traduz os dados que ele deseja transmitir da representação utilizada internamente para uma 
mensagem que possa ser transmitida pela rede; ou seja, os dados são codificados em uma mensagem. 
No lado receptor, a aplicação traduz essa mensagem que chega em uma representação que ela possa 
então processar; ou seja, a mensagem é decodificada. A codificação às vezes é chamada empacotamento 
de argumentos (argument marshalling), e a decodificação às vezes é chamada desempacotamento 
(unmarshalling). Essa terminologia vem do mundo do RPC (Remote Procedure Call), onde o cliente pensa 
que está chamando um procedimento com um conjunto de argumentos, mas esses argumentos são 
então “reunidos e ordenados de um modo apropriado e eficaz”! para formar uma mensagem da rede. 

Você poderia perguntar o que torna esse problema desafiador o suficiente para receber um nome 
como empacotamento. Um motivo é que os computadores representam dados de maneiras diferentes. 
Por exemplo, alguns computadores representam números de ponto flutuante no formato do padrão 
754 do IEEE, enquanto outras máquinas ainda utilizam seu próprio formato não padronizado. Mesmo 
para algo tão simples quanto inteiros, diferentes arquiteturas utilizam diferentes tamanhos (por exem- 
plo, 16 bits, 32 bits, 64 bits). Para piorar as coisas ainda mais, em algumas máquinas os inteiros são 
representados no formato big-endian (o bit mais significativo de uma palavra está no byte com o ende- 
reço mais alto), enquanto em outras máquinas os inteiros são representados no formato little-endian 


Dados da Dados da 

aplicação aplicação 
Codificação de Decodificação 
apresentação de apresentação 


| j 


Mensagem | | Mensagem | --- Mensagem 





FIGURA 7.1 A formatação de apresentação envolve a codificação 
e a decodificação de dados da aplicação. 


1Essa é uma definição de empacotamento retirada do Webster's New Collegiate Dictionary. 
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(2) (17) (34) (126) FIGURA 7.2 Ordem de bytes big-endian e little-endian 


para o inteiro 34.677.374. 
Big-endian | 00000010 00010001 | 00100010 | 01111110 


(126) (34) (17) (2) 
Little-endian | 01111110 | 00100010 | 00010001 | 00000010 


| | 


Endereço Endereço 
baixo alto 


(o bit mais significativo está no byte com o endereço mais baixo). Os processadores MIPSº e PowerPCIM 
são exemplo de máquinas com arquitetura big-endian, e a família x86 da Intelº é um exemplo de uma 
arquitetura little-endian. Por exemplo, as representações big-endian e little-endian do inteiro 34.677.374 
são dadas na Figura 7.2. 

Outro motivo para o empacotamento ser difícil é que os programas de aplicação são escritos em diferentes 
linguagens, e mesmo quando você está usando uma única linguagem, pode haver mais de um compilador. 
Por exemplo, os compiladores possuem muitas variações no modo como eles dispõem estruturas (registros) 
na memória, por exemplo, quantos bytes de preenchimento eles colocam entre os campos que compõem a 
estrutura. Assim, você não poderia simplesmente transmitir uma estrutura de uma máquina para outra, mes- 
mo que as duas máquinas tivessem a mesma arquitetura e o programa fosse escrito na mesma linguagem, 
pois o compilador na máquina de destino poderia alinhar os campos da estrutura de formas diferentes. 


7.1.1 Taxonomia 


Embora qualquer um que já tenha trabalhado no empacotamento de argumentos lhe diria que não existe 
tanta complicação envolvida — isso é apenas uma questão de mexer com bits —, existe uma quantidade 
surpreendente de decisões de projeto que você precisa tomar. Começamos dando uma taxonomia sim- 
ples para os sistemas de empacotamento de argumentos. Esta não é a única taxonomia viável, de forma 
alguma, mas é suficiente para cobrir a maioria das alternativas interessantes. 


Tipos de dados 

A primeira questão é que tipos de dados o sistema irá admitir. Em geral, podemos classificar os tipos 
admitidos por um mecanismo de empacotamento de argumentos em três níveis. Cada nível complica 
a tarefa enfrentada pelo sistema de empacotamento. 

No nível mais baixo, um sistema de empacotamento opera sobre algum conjunto de tipos básicos. 
Normalmente, os tipos básicos incluem inteiros, números de ponto flutuante e caracteres. O sistema 
também poderia admitir tipos ordinais e booleanos. Conforme já descrevemos, a implicação do conjunto 
de tipos básicos é que o processo de codificação precisa ser capaz de converter cada tipo básico de uma 
representação para outra, por exemplo, converter um inteiro de big-endian para little-endian. 

No nível seguinte estão os tipos simples — estruturas e vetores. Embora a princípio possa parecer 
que os tipos simples não complicam o empacotamento de argumentos, na verdade eles complicam. O 
problema é que os compiladores usados para compilar programas de aplicação às vezes inserem bytes 
de preenchimento entre os campos que compõem a estrutura, a fim de alinhar esses campos em limites de 
palavras. O sistema de empacotamento normalmente empacota as estruturas de modo que elas não 
contenham bytes de preenchimento. 

No nível mais alto, o sistema de empacotamento poderia ter que lidar com os tipos complexos — 
aqueles tipos que são construídos usando ponteiros. Ou seja, a estrutura de dados que um programa deseja 
enviar a outro poderia não estar contida em uma única estrutura, mas em vez disso poderia envolver ponteiros 
de uma estrutura para outra. Uma árvore é um bom exemplo de um tipo complexo, que envolve ponteiros. 
Logicamente, o codificador de dados precisa preparar a estrutura de dados para transmissão pela rede, pois 
os ponteiros são implementados por endereços de memória, e só porque uma estrutura reside em certo 
endereço da memória em uma máquina não significa que ela residirá no mesmo endereço em outra máquina. 
Em outras palavras, o sistema de empacotamento precisa serializar estruturas de dados complexas. 
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Resumindo, dependendo do quão complicado é o sistema de tipos, a tarefa do empacotamento 
de argumentos normalmente envolve converter os tipos básicos, empacotar as estruturas e serializar as 


estruturas de dados complexas, tudo para formar uma mensagem contígua, que possa ser transmitida 
pela rede. A Figura 7.3 ilustra essa tarefa. 





Estratégia de conversão 

Quando o sistema de tipos é estabelecido, a próxima questão é qual estratégia de conversão o empaco- 
tador de argumentos usará. Existem duas opções gerais: forma intermediária canônica e receptor-acerta. 
Vamos considerar um de cada vez. 

A ideia da forma intermediária canônica é decidir sobre uma representação externa para cada tipo; 
o host emissor traduz de sua representação interna para essa representação externa antes de enviar 
os dados, e o receptor traduz dessa representação externa para sua representação local ao receber os 
dados. Para ilustrar a ideia, considere os dados inteiros; outros tipos são tratados de modo semelhante. 
Você poderia declarar que o formato big-endian será usado como representação externa para inteiros. 
O host emissor precisa traduzir cada inteiro que envia para o formato big-endian, e o host receptor 
precisa traduzir inteiros big-endian para qualquer representação que ele utilize. (E isso é o que é feito na 
Internet para os cabeçalhos de protocolo.) Naturalmente, determinado host já poderia usar o formato 
big-endian, caso em que nenhuma conversão seria necessária. 

A alternativa, que às vezes é chamada receptor-acerta (receiver-makes-right), o emissor transmite 
dados em seu próprio formato interno; o emissor não converte os tipos básicos, mas normalmente 
precisa empacotar e serializar estruturas de dados mais complexas. O receptor, então, é responsável 
por traduzir os dados do formato do emissor para seu próprio formato local. O problema com essa es- 
tratégia é que cada host precisa estar preparado para converter dados de todas as outras arquiteturas de 
máquina. Em redes, isso é conhecido como solução N por N: cada uma das N arquiteturas de máquina 
precisa ser capaz de tratar todas as N arquiteturas. Em comparação, em um sistema que usa uma forma 
intermediária canônica, cada host só precisa saber como converter entre sua própria representação e 
uma única outra representação - a externa. 

O uso de um formato externo comum é claramente a coisa correta a fazer, certo? Essa certamente 
tem sido a sabedoria convencional na comunidade de redes durante os 25 últimos anos. Porém, a 
resposta não é definitiva. Acontece que não existem tantas representações diferentes para as diversas 
classes básicas ou, em outras palavras, N não é tão grande. Além disso, o caso mais comum é que duas 
máquinas do mesmo tipo estejam se comunicando entre si. Nessa situação, parece tolice traduzir dados 
da representação dessa arquitetura para alguma representação externa, para depois ter que traduzi-los 
de volta para a representação da mesma arquitetura no receptor. 

Uma terceira opção, embora não conheçamos qualquer sistema existente que a explore, é usar a 
técnica de receptor-acerta se o emissor souber que o destino tem a mesma arquitetura; o emissor usaria 
alguma forma intermediária canônica se as duas máquinas usarem arquiteturas diferentes. Mas como um 
emissor descobriria a arquitetura do receptor? Ele poderia descobrir essa informação ou por um servidor 
de nomes ou primeiro usando um caso de teste simples para ver se o resultado apropriado é obtido. 


E 
OUL 
E 


Empacotador de argumentos 
SE E FIGURA 7.3 Empacotamento de argumentos: conversão, 
empacotamento e serialização. 


Estrutura de dados da aplicação 
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Rótulos 

A terceira questão no empacotamento de argumentos é como o receptor sabe que tipo de dado está 
contido na mensagem que ele recebe. Existem duas abordagens comuns: dados rotulados e dados não 
rotulados. A abordagem rotulada é mais intuitiva e por isso a descrevemos primeiro. 

Um rótulo é qualquer informação adicional incluída em uma mensagem — além da representação 
concreta dos tipos básicos - que ajude o receptor a decodificar a mensagem. Existem vários rótulos 
que possivelmente poderiam ser incluídos em uma mensagem. Por exemplo, cada item de dados 
poderia ter a ele acrescentado um rótulo de tipo. Um rótulo de tipo indica que o valor a seguir é um 
inteiro, um número em ponto flutuante ou outro qualquer. Outro exemplo é o rótulo de tamanho. 
Esse rótulo é usado para indicar o número de elementos em um vetor ou o tamanho de um inteiro. 
Um terceiro exemplo é um rótulo de arquitetura, que poderia ser usado em conjunto com a estratégia 
receptor-acerta para especificar a arquitetura em que os dados contidos na mensagem foram gerados. 
A Figura 7.4 mostra como um inteiro simples de 32 bits poderia ser codificado em uma mensagem 
rotulada. 

A alternativa, logicamente, é não usar rótulos. Mas como o receptor sabe decodificar os dados nesse 
caso? Ele sabe porque foi programado para saber. Em outras palavras, se você chama um procedimento 
remoto usando dois inteiros e um número em ponto flutuante como argumentos, então não há motivo 
para o procedimento remoto inspecionar rótulos para saber o que ele recebeu. Ele simplesmente assume 
que a mensagem contém dois inteiros e um número em ponto flutuante, e decodifica os valores de 
acordo com essa suposição. Observe que, embora isso funcione para a maioria dos casos, uma situação 
em que isso não funciona é quando se envia vetores de tamanho variável. Nesse caso, um rótulo de 
tamanho normalmente é usado para indicar o comprimento do vetor. 

Também vale a pena mencionar que a técnica não rotulada significa que a formatação de apresenta- 
ção é verdadeiramente fim a fim. Não é possível que algum agente intermediário interprete a mensagem 
a menos que os dados sejam rotulados. Por que um agente intermediário precisaria interpretar uma 
mensagem? — você poderia perguntar. Coisas mais estranhas já foram vistas, em sua maioria como 
resultado de soluções paliativas para problemas inesperados que o sistema não foi preparado para 
enfrentar. Projetos de rede mal feitos estão fora do escopo deste livro. 


Stubs 

Um stub é um pedaço de código que implementa o empacotamento de argumentos. Stubs normalmente 
são usados para dar suporte a RPCs. No lado do cliente, o stub empacota os argumentos do procedimento 
em uma mensagem que pode ser transmitida por meio do protocolo RPC. No lado do servidor, o stub 
converte a mensagem de volta para um conjunto de variáveis, que podem ser usadas como argumentos 
para chamar o procedimento remoto. Os stubs podem ser interpretados ou compilados. 

Em uma abordagem baseada em compilação, cada procedimento possui um stub cliente e um stub 
servidor “personalizado”. Embora seja possível escrever stubs de forma manual, eles normalmente são 
gerados por um compilador de stubs, baseado em uma descrição da interface do procedimento. Essa 
situação é ilustrada na Figura 7.5. Como o stub é compilado, ele normalmente é muito eficiente. Em 
uma abordagem baseada em interpretação, o sistema fornece stubs cliente e servidor “genéricos”, cujos 
parâmetros são definidos por uma descrição da interface do procedimento. Como é fácil mudar essa 
descrição, os stubs interpretados têm a vantagem de serem flexíveis. Na prática, os stubs compilados 
são mais comuns. 


7.1.2 Exemplos (XDR, ASN.1, NDR) 


Agora, descrevemos rapidamente três representações populares para os dados da rede em termos dessa 
taxonomia. Usamos o tipo básico inteiro para ilustrar o funcionamento de cada sistema. 





tipo= am=4 valor=417892 








FIGURA 7.4 Um inteiro de 32 bits codificado em uma mensagem rotulada. 
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FIGURA 7.5 Compilador de stubs recebe descrição 
da interface como entrada e gera stubs cliente 
e servidor como saída. 
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XDR 
A Representação Externa de Dados (XDR - External Data Representation) é o formato de rede usado 
com o SunRPC. Na taxonomia que apresentamos, a XDR: 


e Fornece suporte ao sistema completo de tipos da linguagem C, com exceção dos ponteiros para 
função. 

e Define uma forma intermediária canônica. 

e Não usa rótulos (exceto para indicar tamanhos de vetor). 

e Usa stubs compilados. 


Um inteiro XDR é um item de dados de 32 bits que codifica um inteiro em C. Ele é representado na nota- 
ção de complemento de dois, com o byte mais significativo do inteiro em C no primeiro byte do inteiro XDR, 
e o byte menos significativo do inteiro em C no quarto byte do inteiro XDR. Ou seja, a XDR usa o formato 
big-endian para inteiros. A XDR admite inteiros com sinal e sem sinal, assim como a linguagem C. 

A XDR representa vetores de tamanho variável especificando primeiro um inteiro sem sinal (4 bytes) 
que indica o número de elementos no vetor, seguido por essa quantidade de elementos do tipo apro- 
priado. A XDR codifica os componentes de uma estrutura na ordem de sua declaração na estrutura. 
Para vetores e estruturas, o tamanho de cada elemento/componente é representado por um múltiplo 
de 4 bytes. Tipos de dados menores são preenchidos com até 4 bytes repletos de Os. A exceção para essa 
regra de “preenchimento com até 4 bytes” acontece para caracteres, que são codificados usando-se um 
byte para cada um deles. 

O fragmento de código a seguir mostra uma estrutura de exemplo em linguagem C (item) e a rotina 
XDR que codifica/decodifica essa estrutura (xdr item). A Figura 7.6 representa esquematicamente 
a “representação no fio” da XDR para essa estrutura, quando o campo nome possui sete caracteres 
de comprimento e o vetor lista contém três valores. 











H-— Contador -|< Nome =] 
3 7 J O H N S O N 
«+ Lista 1l 
3 497 8321 265 


FIGURA 7.6 Codificação de exemplo de uma estrutura em XDR. 
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Neste exemplo, xdr array, xdr inte xdr string são três funções primitivas fornecidas pela XDR para 
codificar e decodificar vetores, inteiros e cadeias de caracteres, respectivamente. O argumento xdrs 
é uma variável de contexto que a XDR utiliza para manter o controle sobre onde ela se encontra na 
mensagem sendo processada; o argumento inclui um marcador que indica se essa rotina está sendo 
usada para codificar ou decodificar a mensagem. Em outras palavras, rotinas como xdr item são usadas 
no cliente e no servidor. Observe que o programador da aplicação pode escrever a rotina xdr item a mão 
ou usar um compilador de stubs chamado rpcgen (não mostrado) para gerar essa rotina de codificação / 
decodificação. Neste último caso, rpcgen recebe como entrada o procedimento remoto que define 
a estrutura de dados item e gera o stub correspondente. 


tdefine MAXNOME 256; 
#define MAXLISTA 100; 





struct item ( 
int conta; 


char nome [MAXNOME] ; 
int lista [MAXLISTA)]; 
+; 
bool t 
xdr i tem(XDR *xdrs, struct item *ptr) 
{ 
return (xdr int(xdrs, &ptr->conta) && 


xdr string(xdrs, &ptr->nome, MAXNOME) && 
xdr array (xdrs, &«ptr->lista, «ptr->conta, MAXLISTA, 
sizeof (int), xdr int)); 





O desempenho exato da XDR, logicamente, depende da complexidade dos dados. Em um caso 
simples de um vetor de inteiros, onde cada inteiro precisa ser convertido de uma ordem de bytes para 
outra, uma média de três instruções são necessárias para cada byte, significando que a conversão do 
vetor completo é provavelmente limitada pela largura de banda da memória da máquina. Conversões 
mais complexas, que exigem muito mais instruções por byte, serão limitadas pela CPU e, portanto, 
funcionarão com uma taxa de dados menor do que a largura de banda da memória. 


ASN.1 

A Notação de Sintaxe Abstrata Um (ASN.1 — Abstract Syntax Notation One) é um padrão ISO que define, 
entre outras coisas, uma representação para os dados enviados por uma rede. A parte específica da 
representação da ASN.1 é chamada regras de codificação básicas (BER — Basic Encoding Rules). A ASN.1 
fornece suporte ao sistema de tipos da linguagem C sem ponteiros para função, define uma forma 
intermediária canônica e usa rótulos de tipo. Seus stubs podem ser interpretados ou compilados. 
Uma das explicações para a fama da ASN.I BER é que ela é usada pelo padrão SNMP (Simple Network 
Management Protocol) da Internet. 

A ASN. representa cada item de dados com uma tripla na forma: 


« rótulo, tamanho, valor > 


O rótulo geralmente é um campo de 8 bits, embora a ASN.l permita a definição de rótulos com 
múltiplos bytes. O campo tamanho especifica quantos bytes compõem o valor; discutiremos mais sobre 
o campo tamanho um pouco adiante. Os tipos de dados compostos, como as estruturas, podem ser 
formados pelo aninhamento de tipos primitivos, conforme ilustrado na Figura 7.7. 











tipo | tamanho | tipo tamanho «— valor —» tipo tamanho «— valor —+» 





- valor ———————— 





FIGURA 7.7 Tipos compostos criados por meio de aninhamento na ASN.1 BER. 
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T T FIGURA 7.8 Representação ASN.1 BER para um inteiro de 4 bytes. 
INT 4  jæ— inteiro de 4 bytes —— 
l l 
FIGURA 7.9 Representação ASN.1 BER para tamanhos de: (a) 1 byte; 
O , tamanho (b) múltiplos bytes. 
(a) 
1 k k bytes contendo tamanho 
(b) 


Se o valor ocupar 127 ou menos bytes, então o tamanho é especificado usando um único byte. Assim, 
por exemplo, um inteiro de 32 bits é codificado como um tipo de 1 byte, um tamanho de 1 byte e os 4 bytes 
que codificam o inteiro, como ilustra a Figura 7.8. O valor em si, no caso de um inteiro, é representado 
na notação de complemento de dois e no formato big-endian, assim como na XDR. Lembre-se que, 
embora o valor do inteiro seja representado exatamente da mesma maneira na XDR e na ASN.1, a re- 
presentação XDR não possui os rótulos tipo nem tamanho associados a esse inteiro. Esses dois rótulos 
ocupam espaço na mensagem e, mais importante, exigem processamento durante o empacotamento 
e o desempacotamento. Esse é um motivo para a ASN.I não ser tão eficiente quanto a XDR. Outro é que 
o próprio fato de que cada valor de dados é precedido por um campo tamanho significa que o valor dos 
dados provavelmente não se encontrará em uma fronteira natural de bytes (por exemplo, um inteiro 
iniciando em uma fronteira de palavra). Isso complica o processo de codificação / decodificação. 

Se o valor tiver 128 ou mais bytes de comprimento, então múltiplos bytes são usados para es- 
pecificar seu tamanho. Nesse ponto, você pode estar se perguntando por que um byte pode especificar 
um tamanho de até 127 bytes, em vez de 256. O motivo é que 1 bit do campo tamanho é usado para 
indicar a extensão do campo tamanho. Um 0 no oitavo bit indica um campo tamanho com 1 byte. Para 
especificar um tamanho maior, o oitavo bit é fixado em 1, e os outros 7 bits indicam quantos bytes 
adicionais compõem o tamanho. A Figura 7.9 ilustra um tamanho simples de 1 byte e um tamanho 
com múltiplos bytes. 


NDR 

A Representação de Dados de Rede (NDR — Network Data Representation) é o padrão de codificação de 
dados usado no Ambiente de Computação Distribuído (DCE - Distributed Computing Environment, que 
apresentamos na Seção 5.3). Ao contrário da XDR e da ASN. 1, a NDR usa a técnica de receptor-acerta. Ela 
faz isso inserindo um rótulo de arquitetura no início de cada mensagem; os itens de dados individuais 
não são marcados. A NDR usa um compilador para gerar stubs. Esse compilador recebe uma descrição 
de um programa escrito na Linguagem de Definição de Interface (IDL — Interface Definition Language) 
e gera os stubs necessários. A IDL é muito semelhante à linguagem C, e basicamente fornece suporte 
ao sistema de tipos de C. 

A Figura 7.10 ilustra o rótulo de definição de arquitetura de 4 bytes que é incluído no início de cada 
mensagem codificada com a NDR. O primeiro byte contém dois campos de 4 bits. O primeiro campo, 
Reprint, define o formato para todos os inteiros contidos na mensagem. Um 0 nesse campo indica 
inteiros big-endian, e um 1 indica inteiros little-endian. O campo ReprCar indica qual o formato de 
caracteres utilizado: 0 significa ASCII (American Standard Code for Information Interchange) e 1 significa 
EBCDIC (uma alternativa ao ASCII, mais antiga e definida pela IBM). Em seguida, o byte ReprPF define 


0 4 8 16 24 31 
Reprint | ReprCar ReprPF Extensão 1 Extensão 2 


FIGURA 7.10 Rótulo de arquitetura da NDR. 
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qual representação de ponto flutuante está sendo usada: 0 significa IEEE 754, 1 significa VAX, 2 significa 
Cray e 3 significa IBM. Os dois últimos bytes são reservados para uso futuro. Observe que, nos casos 
simples, como vetores de inteiros, a NDR realiza a mesma quantidade de trabalho que a XDR, e por isso 
é capaz de alcançar o mesmo desempenho. 


7.1.3 Linguagens de marcação (XML) 


Embora estejamos discutindo o problema da formatação de apresentação do ponto de vista do RPC — 
ou seja, como você codifica tipos de dados primitivos e estruturas de dados compostas de modo que 
possam ser enviados de um programa cliente para um programa servidor —, o mesmo problema básico 
ocorre em outros cenários. Por exemplo, como um servidor Web descreve uma página Web de modo 
que diversos navegadores (browsers) diferentes saibam o que exibir na tela? Nesse caso específico, a 
resposta é a Linguagem de Marcação de Hipertexto (HTML — HyperText Markup Language), que indica 
que certas cadeias de caracteres devem ser exibidas em negrito ou itálico, que tipo de fonte e tamanho 
devem ser usados, e onde as imagens devem ser posicionadas. 

A enorme popularidade da Web e a disponibilidade de todos os tipos de aplicações e dados nela 
também criaram uma situação em que diferentes aplicações Web precisam se comunicar umas com as 
outras e entender os dados umas das outras. Por exemplo, um site de comércio eletrônico poderia ter 
que falar com o site de uma transportadora para permitir que um cliente acompanhe a movimentação 
de um pacote sem sequer sair do site de comércio eletrônico. Isso, de fato, começa a parecer muito 
com o RPC, e o método usado na Web hoje é permitir que essa comunicação entre servidores Web seja 
baseada na Linguagem de Marcação Extensível (XML - Extensible Markup Language). 

As linguagens de marcação, das quais HTML e XML são exemplos, levam ao extremo a abordagem de 
rotular dados. Os dados são representados como texto, e rótulos de texto, conhecidos como marcação, 
são intercalados com os dados de texto para expressar informações sobre esses dados. No caso da HTML, 
a marcação simplesmente indica como o texto deve ser exibido; outras linguagens de marcação, como 
XML, podem expressar o tipo e a estrutura dos dados. 

A XML na realidade é um arcabouço para definir diferentes linguagens de marcação para diferentes 
tipos de dados. Por exemplo, a XML tem sido usada para definir uma linguagem de marcação que é 
equivalente à HTML, chamada linguagem extensível de marcação de hipertexto XHTML - Extensible 
HyperText Markup Language). A XML define uma sintaxe básica para combinar marcações com dados 
textuais, mas o projetista de uma linguagem de marcação específica precisa nomear e definir suas 
marcações. É uma prática comum referir-se a linguagens individuais baseadas na XML simplesmente 
como XML, mas vamos enfatizar a distinção neste material introdutório. 

XML se parece muito com HTML. Por exemplo, a seguir vemos uma descrição XML de um registro 
de empregado; ele se chama documento XML e poderia ser armazenado em um arquivo chamado em- 
pregado.xml. A primeira linha especifica a versão da XML sendo usada, e as outras linhas especificam 
os quatro campos que compõem o registro do empregado; o último (datacontratado) contém três 
subcampos. Em outras palavras, a XML permite que os usuários especifiquem uma estrutura aninhada 
de pares de rótulo/valor, que é equivalente a uma estrutura em árvore para os dados representados 
(com empregado como raiz). Isso é semelhante à capacidade de representar tipos compostos da XDR, 
ASN.1 e NDR, mas em um formato que pode ser processado por programas e lido por humanos. Mais 
importante, programas como interpretadores (parsers) podem ser usados por diferentes linguagens 
baseadas em XML, pois as definições dessas linguagens são elas mesmas expressas como dados legíveis 
pela máquina que podem ser passados como entradas para os programas. 












a>5</dia> 
Junho</mês> 
>1986</an 
contratado> 
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Embora as marcações e os dados neste documento sejam altamente sugestivos ao leitor humano, é 
a definição da linguagem do registro do empregado que realmente determina quais rótulos são válidos, 
o que eles significam e a quais tipos de dados eles se referem. Sem alguma definição formal das rótulos, 
um leitor humano (ou um computador) não sabe se 1986 no campo ano, por exemplo, é uma cadeia de 
caracteres, um inteiro, um inteiro sem sinal ou um número em ponto flutuante. 

A definição de uma linguagem específica, baseada na XML, é dada por um esquema (ou schema), 
que é um termo de banco de dados para uma especificação de como interpretar uma coleção de 
dados. Várias linguagens de esquema foram definidas para a XML; vamos focalizar aqui o padrão 
dominante, conhecido pelo nome óbvio de XML Schema. Um esquema individual, definido por meio 
do XML Schema, é conhecido como um documento XML Schema (XSD — XML Schema Document). 
A seguir, vemos um XSD para o exemplo empregado.xml; em outras palavras, ele define a linguagem 
seguida pelo documento de exemplo. Ele poderia ser armazenado em um arquivo chamado em- 
pregado.xsd. 





<?xml version="1.0"?> 





<schema xmins=“http://www.w3.0rg/2001/XMLSchema”> 
<element name=“empregado”> 
<complexType> 
<sequence> 





<element name=“nome” type=“string”/> 
<element name=“cargo” type=“string”/> 





lement name=“id” type=“string”/> 

<element name=“datacontratado”> 

<complexType> 
<sequen 





nt name=“dia” type=“integer”/> 
<element name=“mês” type=“string” 
<element name=“ano” type=“integer”/> 











</sequence 
</complexType> 
lement> 
</schema> 





Esse XSD é superficialmente semelhante ao nosso documento de exemplo empregado.xml, mas 
somente porque o XML Schema em si é uma linguagem baseada em XML. Existe um relacionamento 
óbvio entre esse XSD e o documento empregado.xml definido anteriormente. Por exemplo, 


D 


<element name=“cargo” type=“string”/> 


indica que o valor delimitado pela marcação cargo deve ser interpretado como uma cadeia de caracteres 
(string). A sequência e o aninhamento dessa linha no XSD indica que um campo cargo deve ser o segundo 
item em um registro de empregado. 

Diferente de algumas linguagens de esquema, o XML Schema oferece tipos de dados como string 
(cadeia de caracteres), integer (número inteiro), decimal (número decimal) e Boolean (dado booleano). 
Ele permite que os tipos de dados sejam combinados em sequências ou aninhados, como em empregado. 
xsd, para criar tipos de dados compostos. Assim, um XSD define mais do que uma sintaxe; ele define 
seu próprio modelo de dados abstrato. Um documento em conformidade com o XSD representa uma 
coleção de dados em conformidade com o modelo de dados. 

A importância de um XSD definir um modelo de dados abstrato e não apenas uma sintaxe é que 
podem haver outras formas, além da XML, de representar dados em conformidade com o modelo. 
Afinal, o XML tem algumas deficiências como uma representação na rede: ela não é uma linguagem tão 
compacta quanto outras representações de dados, e sua interpretação também é relativamente lenta. 
Diversas representações alternativas, descritas como binárias, estão sendo usadas. A International Stan- 
dards Organization (ISO) publicou uma chamada Fast Infoset, enquanto o World Wide Web Consortium 
(W3C) produziu a proposta Efficient XML Interchange (EXI). As representações binárias sacrificam a 
legibilidade para os humanos em favor da compressão e da interpretação mais rápida. 
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Espaços de nomes no XML 

O XML precisa resolver um problema comum, o de conflitos de nomes.? O problema surge porque as 
linguagens de esquema, como o XML Schema, admitem modularidade, no sentido de que um esquema 
pode ser reutilizado como parte de outro esquema. Suponha que dois XSDs sejam definidos indepen- 
dentemente, e ambos definam o nome de marcação númeroID. Talvez um XSD use esse nome para 
identificar empregados de uma empresa, e o outro XSD o use para identificar notebooks pertencentes 
à empresa. Poderíamos querer reutilizar esses dois XSDs em um terceiro XSD para descrever quais 
ativos estão associados a quais empregados, mas, para fazer isso, precisamos de algum mecanismo 
para distinguir o númeroID do empregado do númeroID do notebook. 

A solução da XML para esse problema são os espaços de nomes (namespaces) XML. Um espaço 
de nomes é uma coleção de nomes. Cada espaço de nomes XML é identificado por um Identificador 
Uniforme de Recurso (URI — Uniform Resource Identifier). Os URIs serão descritos com mais deta- 
lhes na Seção 9.1.2; por enquanto, tudo o que você precisa saber é que os URIs são uma forma de 
identificador globalmente exclusivo.” Um nome de marcação simples, como númeroID, pode ser 
acrescentado a um espaço de nomes desde que ela seja exclusivo dentro desse espaço de nomes. 
Como o espaço de nomes é globalmente exclusivo e o nome simples é exclusivo dentro do espaço de 
nomes, a combinação dos dois é um nome qualificado globalmente exclusivo, que não pode gerar 
conflitos. 

Um XSD normalmente especifica um espaço de nomes de destino com uma linha da seguinte forma: 


targetNamespace="“http://www.exemplo.com/empregado” 


http://www.exemplo.com/empregado é um URI, identificando um espaço de nomes inventado. Toda a 
nova marcação definida nesse XSD pertencerá a esse espaço de nomes. 

Agora, se um XSD quiser referenciar nomes que foram definidos em outros XSDs, ele poderá fazer isso 
qualificando esses nomes com um prefixo de espaço de nomes. Esse prefixo é uma abreviação curta de 
um URI completo, que, na realidade, identifica o espaço de nomes. Por exemplo, a linha a seguir atribui 
emp como o prefixo de espaço de nomes para o espaço de nomes de empregado: 


xmins:emp=“http://www.exemplo.com/empregado” 


Qualquer marcação desse espaço de nomes seria qualificada iniciando-a com emp:, assim como 
ocorre com cargo na linha a seguir: 


<emp:cargo>Lavador de Garrafas</emp:cargo> 


emp:cargo é um nome qualificado, que não entrará em conflito com o nome cargo de algum outro es- 
paço de nomes. 

É incrível como a XML agora é utilizada em aplicações que variam desde a comunicação no estilo RPC 
entre serviços baseados na Web até ferramentas de apoio à produtividade de escritórios e mensagens 
instantâneas. Veremos mais alguns de seus usos no Capítulo 9. Certamente, esse é um dos protocolos 
centrais dos quais as camadas superiores da Internet dependem agora. 


7.2 Dados multimídia 


Os dados multimídia, compostos de áudio, vídeo e imagens, agora compõem a maior parte do tráfego 
na Internet de acordo com muitas estimativas. Esse é um desenvolvimento relativamente recente — 
pode ser difícil de acreditar agora, mas não havia YouTube antes de 2005. Parte daquilo que possibi- 
litou a transmissão amplamente difundida de multimídia pelas redes são os avanços na tecnologia 
de compressão. Como os dados multimídia são consumidos principalmente por humanos usando 


2A nomeação é uma área de problema importante e popular para os cientistas da computação. Falaremos muito mais sobre 
espaços de nomes (namespaces) quando examinarmos o DNS - o esquema de nomeação de hosts da Internet - na Seção 9.3.1. 
30s URLs do HTTP são um tipo de URI em particular. 
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seus sentidos — visão e audição — e processados pelo cérebro humano, existem desafios únicos em 
sua compressão. Você deseja tentar manter as informações mais importantes para um ser humano, 
enquanto descarta qualquer coisa que não melhore a percepção humana com respeito à experiência 
visual ou auditiva. Logo, tanto a ciência da computação como o estudo da percepção humana en- 
tram em cena. Nesta seção, veremos alguns dos principais esforços na representação e compressão 
de dados de multimídia. 

Os usos da compressão não estão limitados a dados multimídia, naturalmente — por exemplo, você 
pode muito bem ter usado um utilitário como zip ou compress para comprimir arquivos antes de 
enviá-los por uma rede, ou para descomprimir um arquivo de dados após obtê-lo na rede. Acontece 
que as técnicas usadas para comprimir dados — que normalmente são sem perdas, pois a maioria das 
pessoas não gosta de perder dados de um arquivo — também aparecem como parte da solução para a 
compressão de multimídia. Em comparação, a compressão com perdas, normalmente usada para dados 
multimídia, não promete que os dados recebidos são exatamente os mesmos dados transmitidos. 
Isso porque os dados multimídia normalmente contêm informações que são de pouca utilidade para 
o humano que as recebe. Nossos sentidos e cérebro só podem perceber uma certa quantidade de 
detalhe. Eles também são muito bons em preencher as partes que faltam e até mesmo corrigir alguns 
erros naquilo que veem ou escutam. Além disso, os algoritmos com perdas normalmente conseguem 
taxas de compressão muito melhores do que seus equivalentes sem perdas; elas podem chegar a dez 
vezes ou mais. 

Para ter uma ideia de como a compressão tem sido importante para a popularização da multimídia 
em rede, considere o exemplo a seguir. Uma tela de TV de alta definição tem algo como 1080 x 1920 
pixels, cada um deles com 24 bits de informações de cores, de modo que cada quadro tem 


1080 x 1920 x 24 = 50Mb 


de forma que, se você quiser enviar 24 quadros por segundo, isso equivaleria a mais de 1 Gbps. Isso 
é muito mais do que a maioria dos usuários da Internet é capaz de acessar, com uma boa margem. 
Em comparação, as técnicas de compressão modernas podem levar um sinal de HDTV de qualidade 
razoavelmente alta para a faixa de 10 Mbps, uma redução de 100 vezes e bem dentro do alcance 
de muitos usuários de banda larga. Ganhos de compressão semelhantes se aplicam ao vídeo com 
qualidade inferior, como clipes do YouTube — o vídeo na Web nunca teria alcançado sua popularidade 
atual sem a compressão, para que todos esses vídeos de entretenimento fossem compatíveis com a 
largura de banda das redes de hoje. 

As técnicas de compressão aplicadas à multimídia têm sido uma área de grande inovação nos últimos 
anos, principalmente a compressão com perdas. Porém, as técnicas sem perdas também têm um papel 
importante a desempenhar. Na realidade, a maioria das técnicas com perdas inclui algumas etapas que 
são sem perdas, de modo que começamos nossa discussão com uma visão geral da compressão sem 
perdas. 


7.2.1 Técnicas de compressão sem perdas 


De muitas maneiras, a compressão é inseparável da codificação de dados. Ou seja, pensando em como 
codificar um bloco de dados em um conjunto de bits, poderíamos muito bem pensar em como codificar 
os dados no menor conjunto de bits possível. Por exemplo, se você tiver um bloco de dados composto 
de 26 símbolos de A até Z, e se todos esses símbolos tiverem uma chance igual de ocorrerem no bloco de 
dados que você está codificando, então a codificação de cada símbolo em 5 bits é o melhor que você 
pode fazer (pois 2º=32 é a menor potência de 2 acima de 26). Porém, se o símbolo R ocorre em 50% do 
tempo, então seria uma boa ideia usar menos bits para codificar R do que para codificar qualquer um 
dos outros símbolos. Em geral, se você souber a probabilidade relativa com que cada símbolo ocorrerá 
nos dados, então poderá atribuir um número diferente de bits necessários para codificar determinado 
bloco de dados. Essa é a ideia essencial dos códigos de Huffman, um dos primeiros desenvolvimentos 
importantes na compressão de dados. 
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QUANDO COMPRIMIR? 


Pode parecer que a compressão dos seus dados antes de enviá-los sempre seja uma boa ideia, pois a rede 
poderia entregar os dados comprimidos em menos tempo do que os dados não comprimidos. Porém, isso 
não necessariamente acontece. Os algoritmos de compressão/descompressão normalmente envolvem 
cálculos demorados. A pergunta que você precisa fazer é se o tempo gasto para comprimir/descomprimir 

os dados compensará, devido a fatores como velocidade de processador do host e largura de banda da rede. 
Especificamente, se B, é a largura de banda média em que os dados podem ser processados pelo compressor 
e descompressor (em série), B, é a largura de banda da rede (incluindo os custos de processamento da rede) 
para dados não comprimidos e r é a razão de compressão média, e se considerarmos que todos os dados 

são comprimidos antes que qualquer um deles seja transmitido, então o tempo gasto para enviar x bytes de 
dados não comprimidos é: 


x/B, 
enquanto o tempo para comprimi-los e enviar os dados comprimidos é: 


x/B.+x/(1B,) 


Assim, a compressão é benéfica se 


x/B+x/(rB )<x/B, 


que é equivalente a: 
B.>r/(r-1)xB, 


Por exemplo, para uma razão de compressão de 2, B, teria que ser maior do que 2 x B, para que a 
compressão fizesse sentido. 

Para muitos algoritmos de compressão, podemos não precisar comprimir o conjunto de dados inteiro 
antes de iniciar a transmissão (a realização de uma videoconferência seria impossível se fizéssemos 
isso), mas primeiro precisamos coletar alguma quantidade de dados (talvez alguns quadros de vídeo). 

A quantidade de dados necessária para “encher o tubo” nesse caso seria usada como o valor de x na equação 
acima. 

Naturalmente, quando falamos sobre algoritmos de compressão com perdas, os recursos de 
processamento não são o único fator. Dependendo da aplicação exata, os usuários estão dispostos a fazer 
escolhas muito diferentes para alcançar um equilíbrio entre largura de banda (ou atraso) e extensão da 
perda de informações ocasionada pela compressão. Por exemplo, um radiologista lendo um resultado de 
mamografia provavelmente não tolerará qualquer perda significativa na qualidade da imagem, e pode muito 
bem tolerar um atraso de várias horas até obter uma imagem por uma rede. Por outro lado, ficou bem claro 
que muitas pessoas tolerarão uma qualidade de áudio questionável em troca de ligações telefônicas globais 
gratuitas (sem falar na capacidade de falar ao telefone enquanto dirige). 





Codificação RLE 

A codificação RLE (Run Length Encoding ou codificação por carreira) é uma técnica de compressão 
extremamente simples. A ideia é substituir ocorrências consecutivas de determinado símbolo por 
apenas uma cópia do símbolo, mais um contador de quantas vezes esse símbolo ocorre — daí o nome 
run length (tamanho corrido). Por exemplo, a cadeia de caracteres AAABBCDDDD seria codificada 
como 3A2B1C4D. 

A codificação RLE se tornou muito útil para comprimir algumas classes de imagens. Ela pode ser usa- 
da nesse contexto comparando valores de pixels adjacentes e depois codificando apenas as mudanças. 
Para imagens que possuem grandes regiões homogêneas, essa técnica é muito eficiente. Por exemplo, 
não é raro que a codificação RLE alcance taxas de compressão na ordem de 8 para 1 com imagens de 
texto digitalizadas. A codificação RLE funciona bem com tais arquivos porque eles normalmente contêm 
uma grande quantidade de espaço em branco, que pode ser removido. Na verdade, a codificação RLE é 
o principal algoritmo de compressão utilizado para transmitir fax. Contudo, para imagens até mesmo 
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com um pequeno grau da variação local, não é raro que a compressão na realidade aumente o tamanho 
em bytes da imagem, pois ainda são necessários 2 bytes para representar um único símbolo quando 
esse símbolo não é repetido. 


Modulação por Código de Pulsos Diferencial 

Outro algoritmo de compressão sem perdas simples é o de modulação por código de pulsos diferencial 
(DPCM - Differential Pulse Code Modulation). A ideia aqui é primeiro gerar um símbolo de referência e, 
depois, para cada símbolo presente nos dados, gerar a diferença entre esse símbolo e o de referência. Por 
exemplo, usando o símbolo A como referência, a cadeia de caracteres AAABBCDDDD seria codificada 
como A0001123333, pois A é igual ao símbolo de referência, B tem uma diferença de 1 em relação ao 
símbolo de referência, e assim por diante. Observe que esse exemplo simples não ilustra o benefício 
real do DPCM, que é: quando as diferenças são pequenas, elas podem ser codificadas com menos bits 
do que o próprio símbolo. Nesse exemplo, o intervalo de diferenças 0-3 pode ser representado com 2 
bits cada, em vez de 7 ou 8 bits necessários pelo caractere inteiro. Quando a diferença se torna muito 
grande, um novo símbolo de referência é selecionado. 

A DPCM funciona melhor do que a codificação RLE para a maioria das imagens digitais, pois 
aproveita o fato de que pixels adjacentes normalmente são semelhantes. Devido a essa correlação, 
o intervalo dinâmico das diferenças entre os valores de pixels adjacentes pode ser muito menor que o 
intervalo dinâmico da imagem original, e esse intervalo, portanto, pode ser representado usando 
menos bits. Usando DPCM, medimos razões de compressão de 1,5 para 1 nas imagens digitais. A DPCM 
também funciona para áudio, pois amostras adjacentes de uma forma de onda de áudio provavelmente 
possuem valores próximos. 

Uma técnica ligeiramente diferente, chamada codificação delta, simplesmente codifica um símbolo 
como a diferença do anterior. Assim, por exemplo, AAABBCDDDD seria representado como A001011000. 
Observe que a codificação delta provavelmente funciona bem para a codificação de imagens nas quais 
os pixels adjacentes são semelhantes. Também é possível aplicar a codificação RLE após a codificação 
delta, pois poderíamos encontrar longas sequências de Os se houver muitos símbolos semelhantes um 
ao lado do outro. 


Métodos baseados em dicionário 

O último método de compressão sem perdas que consideramos é a abordagem baseada em dicionário, 
da qual o algoritmo de compressão Lempel-Ziv (LZ) é o mais conhecido!. Os comandos compress e gzip 
do Unix utilizam variações do algoritmo LZ. 

A ideia do algoritmo de compressão baseado em dicionário é montar um dicionário (tabela) de 
cadeias de caracteres de tamanhos variáveis (pense nelas como frases comuns) que você espera 
encontrar nos dados, e depois substituir cada uma dessas cadeias quando ela aparecer nos dados pelo 
índice correspondente no dicionário. Por exemplo, em vez de trabalhar com caracteres individuais 
nos dados de texto, você poderia tratar cada palavra como uma cadeia de caracteres e gerar um índice 
no dicionário para essa palavra. Para detalhar mais esse exemplo, a palavra compression tem o índice 
4.978 em determinado dicionário; ela é a 4.978º palavra em /usr/share/dict/words. Para comprimir um 
corpo de texto, toda vez que a cadeia de caracteres “compression” aparecesse, ela seria substituída por 
4.978. Como esse dicionário específico tem mais de 25.000 palavras, seriam necessários 15 bits para 
codificar o índice, significando que a string “compression” poderia ser representada em 15 bits, em vez 
de 77 bits necessários pelo ASCII de 7 bits. Essa é uma taxa de compressão de 5 para 1! Em outro ponto de 
dados, pudemos obter uma taxa de compressão de 2 para 1 quando aplicamos o comando compress 
ao código fonte dos protocolos descritos neste livro. 

Naturalmente, isso nos leva à questão sobre de onde vem o dicionário. Uma opção é definir um dicio- 
nário estático, de preferência que seja adaptado aos dados sendo comprimidos. Uma solução mais geral, 
e que é utilizada pela compressão LZ, é definir de modo adaptável o dicionário com base no conteúdo dos 
dados sendo comprimidos. Nesse caso, porém, o dicionário construído durante a compressão precisa ser 


“Uma variante do algoritmo é o LZW (Lempel-Ziv-Welch), que inclui alguns refinamentos introduzidos por Welch no 
algoritmo originalmente proposto por Lempel e Ziv (N.T.). 
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enviado juntamente com os dados, para que a parte de descompressão do algoritmo possa realizar seu 
trabalho. O modo exato como você monta um dicionário adaptável tem sido assunto de muita pesquisa; 
discutimos alguns artigos importantes sobre o assunto ao final deste capítulo. 


7.2.2 Representação e compressão de imagem (GIF, JPEG) 


Dado o aumento no uso de imagens digitais nos últimos anos — esse uso foi expandido pela invenção 
de monitores gráficos, e não por redes de alta velocidade -, a necessidade de formatos de representação 
padrão e algoritmos de compressão projetados para dados de imagens digitais cresceu e se tornou cada 
vez mais crítica. Em resposta a essa necessidade, a ISO definiu um formato de imagem digital conhecido 
como JPEG, cujo nome vem do Joint Photographic Experts Group (Grupo Conjunto de Especialistas em 
Fotografia), que o projetou. (O “Joint” em JPEG significa um esforço conjunto entre ISO e ITU.) O JPEG é 
o formato mais usado atualmente para imagens. No coração da definição do formato está um algoritmo 
de compressão, que descrevemos em seguida. Muitas técnicas usadas no JPEG também aparecem no 
MPEG, o conjunto de padrões para compressão e transmissão de vídeo, criado pelo Moving Picture 
Experts Group (Grupo de Especialistas em Imagens em Movimento). 

Antes de nos aprofundarmos nos detalhes do JPEG, observamos que existem muitas etapas para 
passar de uma imagem digital para uma representação comprimida dessa imagem, que possa ser 
transmitida, descomprimida e exibida corretamente por um receptor. Você provavelmente sabe que as 
imagens digitais são compostas de pixels (daí os megapixels anunciados em propagandas de câmeras 
digitais). Cada pixel representa um local na grade bidimensional que compõe a imagem e, para imagens 
coloridas, cada pixel tem algum valor numérico representando uma cor. Existem várias maneiras de 
representar cores, conhecidas como espaços de cor; a mais conhecida é o RGB (Red, Green, Blue ou 
Vermelho, Verde, Azul). Você pode pensar em uma cor como sendo uma quantidade de três dimensões — 
pode-se criar qualquer cor a partir da luz vermelha, verde e azul em diferentes quantidades. Em um 
espaço tridimensional, existem muitas maneiras diferentes e válidas de descrever um ponto qualquer 
(considere as coordenadas Cartesiana e polar, por exemplo). De modo semelhante, existem várias 
maneiras de descrever uma cor usando três quantidades, e a alternativa mais comum ao RGB é o YUV. 
OY é a luminância, ou aproximadamente o brilho geral do pixel, e o U e o V contêm a crominância, ou 
informação de cor. Para confundir ainda mais, também existem algumas variantes do espaço de cores 
YUV. Mais adiante, veremos mais sobre isso. 

Aimportância desta discussão é que a codificação e a transmissão de imagens coloridas (paradas ou 
em movimento) requer um acordo entre as duas extremidades sobre o espaço de cores. Caso contrário, 
logicamente, você acabaria com as cores sendo exibidas pelo receptor diferentes daquelas que foram 
capturadas pelo emissor. Logo, entrar em acordo sobre uma definição do espaço de cores (e talvez um 
modo de comunicar qual espaço de cores em particular está sendo usado) faz parte da definição de 
qualquer formato de imagem ou vídeo. 

Vejamos o exemplo do Formato para Troca de Gráficos (Graphical Interchange Format — GIF). O GIF 
usa o espaço de cores RGB e começa com 8 bits para representar cada uma das três dimensões de cores, 
gerando um total de 24 bits. Porém, ao invés de enviar esses 24 bits por pixel, o GIF primeiro reduz as 
imagens coloridas de 24 bits para imagens coloridas de 8 bits. Isso é feito identificando-se as cores usadas 
na figura, das quais normalmente haverá consideravelmente menos de 2%, e depois escolhendo-se as 
256 cores que mais se aproximam das cores usadas na figura. Contudo, pode haver mais de 256 cores, 
de modo que o truque é não distorcer muito a cor escolhendo 256 cores de modo que nenhum pixel 
tenha sua cor muito alterada. 

As 256 cores são armazenadas em uma tabela, que pode ser indexada usando um número de 
8 bits, e o valor para cada pixel é substituído pelo índice apropriado. Observe que esse é um exemplo 
de compressão com perdas para qualquer figura com mais de 256 cores. O GIF em seguida, executa uma 
variante do LZ sobre o resultado, tratando sequências comuns de pixels como cadeias de caracteres 
que compõem o dicionário — uma operação sem perdas. Usando essa técnica, o GIF às vezes é capaz de 
alcançar taxas de compressão na ordem de 10 para 1, mas somente quando a imagem consiste em um 
número relativamente pequeno de cores distintas. O uso do GIF é adequado para logotipos gráficos, por 
exemplo. Imagens de cenas naturais, que normalmente incluem um espectro de cores mais contínuo, 
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não podem ser comprimidas nessa taxa usando o GIF Também não é muito difícil para o olho humano 
detectar a distorção causada pela redução de cores com perdas do GIF em alguns casos. 

O formato JPEG é muito mais adequado para imagens fotográficas, como seria de se esperar pelo 
nome do grupo que o criou. O JPEG não reduz o número de cores, como faz o GIF Em vez disso, o JPEG 
começa transformando as cores RGB (que são aquilo que você normalmente recebe de uma câmera 
digital) para o espaço YUV. O motivo para isso tem a ver com o modo como o olho percebe as imagens. 
Existem receptores no olho para o brilho, e receptores separados para cores. Como somos muito bons 
em perceber variações no brilho, faz sentido gastar mais bits na transmissão da informação de brilho. 
Como o componenteY do YUV é equivalente ao brilho do pixel, podemos comprimir esse componente 
separadamente e, de forma menos agressiva, dos outros dois componentes (crominância). 

Conforme observamos, YUV e RGB são formas alternativas de descrever um ponto em um espaço tri- 
dimensional, e é possível fazer a conversão de um espaço de cores para outro usando equações lineares. 
Para um espaço YUV que normalmente é usado para representar imagens digitais, as equações são: 


Y=0,299R+0,587G+0,114B 
U=(B-Y)x0,565 
V=(R-Yx0,713 


Os valores exatos das constantes aqui não são importantes, desde que o codificador e o decodificador 
entrem em acordo sobre os seus valores. (O decodificador terá que aplicar as transformações inversas 
para recuperar os componentes RGB necessários para repassar ao monitor.) As constantes, porém, são 
cuidadosamente escolhidas com base na percepção humana da cor. Você pode ver que Y, a luminância, 
é a soma dos componentes vermelho, verde e azul, enquanto U eV são os componentes da diferença 
entre cores. U representa a diferença entre a luminância e o azul, e V a diferença entre a luminosidade 
e o vermelho. Você poderá notar que a definição de R, Ge B com seus valores máximos (que seriam 
255 para representações de 8 bits) também produzirá um valor de Y=255, enquanto U e V nesse 
caso seriam zero. Ou seja, um pixel totalmente branco é dado por (255, 255, 255) no espaço RGB e por 
(255, 0, 0) no espaço YUV. 

Quando a imagem tiver sido transformada para o espaço YUV, podemos pensar em comprimir cada um 
dos três componentes separadamente. Queremos ser mais agressivos na compressão dos componentes 
U eV, aos quais os olhos humanos são menos sensíveis. Um modo de comprimir os componentes U eV é 
por meio de subamostragem. A ideia básica da subamostragem é apanhar uma série de pixels adjacentes, 
calcular o valor U ouV médio para esse grupo de pixels e transmitir isso, em vez de enviar o valor de cada 
pixel. A Figura 7.11 ilustra esse ponto. O componente da luminância (Y) não é subamostrado, de modo 
que o valor Y de todos os pixels será transmitido, conforme indicado pela grade de pixels de 16x 16 à es- 
querda. No caso de U eV, tratamos cada grupo de quatro pixels adjacentes como um grupo, calculamos 
a média do valor de U ouV para esse grupo e transmitimos isso. Assim, acabamos com uma grade de 
8x 8 com valores de U eV para transmitir. Assim, neste exemplo, para cada quatro pixels, transmitimos 
seis valores (quatro de Y e um para cada U eV), em vez dos 12 valores originais (quatro para todos os três 
componentes), obtendo uma redução de 50% na quantidade de informação. 








FIGURA 7.11 Subamostragem dos componentes U e V de uma imagem. 
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FIGURA 7.12 Diagrama em blocos da compressão JPEG. 








Vale a pena observar que você poderia ser mais ou menos agressivo na redução, com correspondente 
aumento na compressão e redução na qualidade. A técnica de redução mostrada aqui, em que a crominância 
é subamostrada por um fator de dois nas direções horizontal e vertical (e que é identificada pela notação 
4:2:0), é na realidade muito semelhante à técnica mais comum utilizada pelo JPEG e pelo MPEG. 

Quando a subamostragem termina, temos três grades de pixels para tratar, e cada uma é tratada 
separadamente. A compressão JPEG de cada componente ocorre em três fases, conforme ilustra a 
Figura 7.12. No lado da compressão, a imagem passa por essas três fases, um bloco de 8 x 8 de cada vez. 
A primeira fase aplica a transformada discreta do cosseno (DCT — Discrete Cosine Transform) ao bloco. 
Se você pensar na imagem como um sinal no domínio do espaço, então a DCT transforma esse sinal 
em um sinal equivalente no domínio da frequência espacial. Essa é uma operação sem perdas, mas um 
precursor necessário para a próxima etapa, com perdas. Após a DCT, a segunda fase aplica a quantização 
ao sinal resultante e, ao fazer isso, perde as informações menos significativas contidas nesse sinal. A 
terceira fase codifica o resultado final, mas, ao fazer isso, acrescenta um elemento de compressão sem 
perdas à compressão com perdas alcançada pelas duas primeiras fases. A descompressão segue essas 
mesmas três fases, mas na ordem contrária. 


Fase de DCT 
A DCT é uma transformação bastante relacionada à transformada rápida de Fourier (FFT — Fast Fourier 
Transform). Ela recebe uma matriz 8 x 8 de valores de pixels como entrada e gera uma matriz 8 x 8 de 
coeficientes de frequência. Você pode pensar na matriz de entrada como um sinal de 64 pontos que é 
definido em duas dimensões espaciais (x e y); a DCT divide o sinal em 64 frequências espaciais. Para 
ter uma noção intuitiva da frequência espacial, imagine-se movendo por uma imagem, digamos, na 
direção x. Você veria o valor de cada pixel variando de acordo com alguma função de x. Se esse valor 
mudar lentamente à medida que x aumenta, então ele tem uma frequência espacial baixa, e se mudar 
rapidamente, ele tem uma frequência espacial alta. Assim, as frequências baixas correspondem aos 
elementos com menos detalhados da imagem, enquanto as frequências altas correspondem aos deta- 
lhes. A ideia por trás da DCT é separar os recursos menos detalhados, que são essenciais para a exibição 
da imagem, dos pequenos detalhes, que são menos essenciais e, em alguns casos, mal poderiam ser 
percebidos pelo olho humano. 

A DCT, junto com sua inversa, que é executada durante a descompressão, é definida pelas seguintes 
fórmulas: 
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onde pixel(x,y) é o valor em tons de cinza do pixel na posição (x,y) do bloco 8 x 8 sendo comprimido; 
N=8 nesse caso. 
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O primeiro coeficiente de frequência, na posição (0,0) da matriz de saída, é chamado coeficiente 
DC. Intuitivamente, podemos ver que o coeficiente DC é uma medida do valor médio dos 64 pixels de 
entrada. Os outros 63 elementos da matriz de saída são chamados coeficientes AC. Eles adicionam a 
informação de frequência espacial mais alta a esse valor médio. Assim, quando você vai do primeiro 
coeficiente de frequência para o 64º coeficiente de frequência, está se movendo da informação de 
frequência baixa para a informação de frequência alta, dos traçados menos detalhados da imagem até 
os detalhes cada vez mais minuciosos. Esses coeficientes de frequência mais alta são gradativamente 
menos importantes para a qualidade percebida da imagem. É a segunda fase do JPEG que decide quais 
partes de quais coeficientes serão removidas. 


Fase de quantização 

A segunda fase do JPEG é aquela em que a compressão introduz perdas. A DCT por si só, não perde 
informações, apenas transforma a imagem para uma forma que facilite a identificação, de quais in- 
formações devem ser removidas. (Embora não haja perda de informações, na realidade existe alguma 
perda de precisão durante a fase de DCT, devido ao uso de aritmética de ponto fixo.) A quantização é 
fácil de entender — é simplesmente uma questão de descartar os bits não significativos dos coeficientes 
de frequência. 

Para ver como funciona a fase de quantização, imagine que você queira comprimir alguns núme- 
ros inteiros menores que 100, por exemplo, 45, 98, 23, 66 e 7. Se você decidisse que conhecer esses 
números truncados para o múltiplo de 10 mais próximo é suficiente para as suas finalidades, então 
poderia dividir cada número pelo quantum 10 usando a aritmética de inteiros, gerando 4, 9, 2, 6 e 0. 
Cada um desses números pode ser codificado em 4 bits, em vez dos 7 bits necessários para codificar 
os números originais. 

Em vez de usar o mesmo quantum para todos os 64 coeficientes, o JPEG usa uma tabela de quantiza- 
ção que indica o quantum a ser usado para cada um dos coeficientes, conforme especificado na fórmula 
dada a seguir. Você pode pensar nessa tabela (Quantum) como um parâmetro que pode ser definido 
para controlar quanta informação é perdida e, de modo correspondente, quanta compressão é obtida. 
Na prática, o padrão JPEG especifica um conjunto de tabelas de quantização que se provaram eficientes 
na compressão de imagens digitais; um exemplo de tabela de quantização aparece na Tabela 7.1. Em 
tabelas como esta, os coeficientes baixos possuem um quantum próximo de 1 (significando que pouca 
informação de baixa frequência é perdida) e os coeficientes altos possuem valores maiores (significando 
que mais informações de alta frequência são perdidas). Observe que, como resultado de tais tabelas 
de quantização, muitos dos coeficientes de alta frequência acabam valendo 0 após a quantização, 
tornando-os aptos para mais compressão na terceira fase. 

A equação básica da quantização é: 


ValorQuantizado(i,) = ArredondamentoInteiro(DC T(i;)/Quantum(ij) 
onde 


. f[x+0,5] sex20 
Arredondamentolnteiro(x) = [x-0,5] æx<0 


Tabela 7.1 Exemplo de tabela de quantização do JPEG 


3 5 PÁ 9 11 13 15 17 
5 7 9 11 13 15 17 19 
7. 9 il 13 15 17 19 21 
Quantum = 9 11 13 15 17 19 21 23 
lil 13 15 17 19 21 23 25 
13 15 17 19 21 23 25 27 
15 17 19 21 23 25 27 29 


17 19 21 23 25 27 29 31 
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A descompressão é, então, definida simplesmente como: 


DCi j) = ValorQuantizado(ij) x Quantum(ij) 


Por exemplo, se o coeficiente de DC (ou seja, DCT(0,0)) para determinado bloco for igual a 25, então 
a quantização desse valor usando a Tabela 7.1 resultaria em: 


[25/3+0,5]=8 


Durante a descompressão, esse coeficiente seria então recuperado como: 


8x3=24 


Fase de codificação 

A fase final do JPEG codifica os coeficientes de frequência quantizados para uma forma compacta. Isso 
resulta em compressão adicional, mas essa compressão é sem perdas. Começando com o coeficiente 
de DC na posição (0,0), os coeficientes são processados na sequência de ziguezague mostrada na Fi- 
gura 7.13. Junto com esse ziguezague, uma forma de codificação em carreira é utilizada — a codificação 
RLE é aplicada somente aos coeficientes 0, o que é significativo porque muitos dos últimos coeficientes 
são 0. Os valores de coeficiente individuais são então codificados usando um código de Huffman. (O 
padrão JPEG permite que o implementador utilize uma codificação aritmética no lugar do código de 
Huffman.) 

Além disso, como o coeficiente DC contém uma grande porcentagem de informações sobre o bloco 
de 8 x 8da imagem original, e as imagens normalmente mudam lentamente de um bloco para outro, 
cada coeficiente DC é codificado como a diferença do coeficiente DC anterior. Essa é a técnica de 
codificação delta descrita na Seção 7.2.1. 

O JPEG inclui uma série de variações que controlam quanta compressão você consegue versus a 
fidelidade da imagem. Isso pode ser feito, por exemplo, usando diferentes tabelas de quantização. Essas 
variações, mais o fato de que imagens diferentes possuem características diferentes, impossibilitam 
dizer com precisão as taxas de compressão que podem ser alcançadas com o JPEG. Taxas de 30 para 1 
são comuns, e taxas mais altas certamente são possíveis, mas os artefatos (distorção observável devido 
à compressão) tornam-se mais severas para taxas mais altas. 


7.2.3 Compressão de vídeo (MPEG) 


Agora, vamos voltar nossa atenção para o formato MPEG, cujo nome vem do Moving Picture Experts 
Group (Grupo de Especialistas em Imagens em Movimento), que o definiu. Em uma primeira aproxi- 
mação, uma imagem em movimento (ou seja, vídeo) é simplesmente uma sucessão de figuras paradas — 
também chamadas quadros ou imagens — exibidas em alguma taxa de vídeo. Cada um desses quadros 
pode ser comprimido usando a mesma técnica baseada em DCT usada no JPEG. Porém, parar nesse 
ponto seria um erro, pois isto deixaria de remover a redundância entre os quadros, que existe em uma 
sequência de vídeo. Por exemplo, dois quadros de vídeo sucessivos terão informações quase idênticas 












































FIGURA 7.13 Travessia em ziguezague dos coeficientes de frequência quantizados. 
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se não houver muito movimento na cena, de modo que seria desnecessário enviar a mesma informação 
duas vezes. Mesmo quando existe movimento, pode haver muita redundância, pois um objeto em 
movimento pode não mudar de um quadro para o seguinte; em alguns casos, somente sua posição 
muda. O MPEG leva em consideração essa redundância. O MPEG também define um mecanismo para 
codificar um sinal de áudio juntamente com o vídeo, mas vamos considerar apenas o aspecto de vídeo 
do MPEG nesta seção. 


Tipos de quadro 

O MPEG recebe uma sequência de quadros de vídeo como entrada e os comprime para três tipos de 
quadro, chamados quadros I (intraimagem), quadros P (imagem prevista) e quadros B (imagem prevista 
bidirecional). Cada quadro de entrada é comprimido para um desses três tipos. Os quadros I podem ser 
imaginados como quadros de referência; eles são autocontidos, não dependendo de quadros anteriores 
nem posteriores. A princípio, um quadro I é apenas a versão JPEG comprimida do quadro correspondente 
na origem do vídeo. Quadros P e B não são autocontidos; eles especificam diferenças relativas a algum 
quadro de referência. Mais especificamente, um quadro P especifica as diferenças relativas a um quadro 
I anterior, enquanto um quadro B é uma interpolação entre os quadros I ou P anterior e seguinte. 

A Figura 7.14 ilustra uma sequência de sete quadros de vídeo que, depois de serem comprimidos 
pelo MPEG, resultam em uma sequencial de quadros I, P e B. Os dois quadros I são isolados; cada um 
pode ser descomprimido no receptor independentemente de quaisquer outros quadros. O quadro P 
depende do quadro I anterior; ele só pode ser descomprimido no receptor se o quadro I anterior também 
chegar. Cada um dos quadros B depende do quadro I ou P anterior e do quadro I ou P seguinte. Ambos 
os quadros de referência precisam chegar no receptor antes que o MPEG possa descomprimir o quadro 
B para reproduzir o quadro de vídeo original. 

Observe que, como cada quadro B depende de um quadro posterior na sequência, os quadros com- 
primidos não são transmitidos na ordem sequencial. Ao invés disso, a sequência IB B P B B I mostrada 
na Figura 7.14 é transmitida como IP B B I B B. Além disso, o MPEG não define a razão de quadros 
I para quadros P e B; essa razão pode variar, dependendo da compressão exigida e da qualidade da 
imagem. Por exemplo, é permitido transmitir apenas quadros I. Isso seria semelhante a usar JPEG para 
comprimir o vídeo. 

Ao contrário da discussão anterior sobre JPEG, focalizamos a seguir a decodificação de um fluxo 
MPEG. Ela é um pouco mais fácil de descrever e é a operação mais implementada nos sistemas de rede 
de hoje, pois a codificação MPEG é tão dispendiosa que normalmente é feita off-line (ou seja, não em 
tempo real). Por exemplo, em um sistema de vídeo sob demanda, o vídeo seria codificado e armazenado 
em disco antes de ser usado. Quando um espectador quisesse ver o vídeo, o fluxo MPEG seria então 
transmitido para a máquina do espectador, que decodificaria e exibiria o fluxo em tempo real. 

Vamos examinar mais de perto os três tipos de quadro. Como já dissemos, os quadros I são aproxi- 
madamente iguais à versão comprimida usando JPEG do quadro original. A diferença principal é que 
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FIGURA 7.14 Sequência de quadros |, P e B gerados pelo MPEG. 
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Quadro colorido FIGURA 7.15 Cada quadro como uma coleção 
de macroblocos. 


Região de er Macrobloco 16 x 16 
16x16 er com componente Y 
pixels 22 


Macrobloco 8 x 8 
com componente U 





Macrobloco 8 x 8 
com componente V 




















o MPEG trabalha em unidades de 16 x 16 macroblocos. Para um vídeo colorido representado em YUV, 
os componentes U e V em cada macrobloco são reduzidos para um bloco 8 x 8, conforme discutimos 
anteriormente, no contexto do JPEG. Cada sub-bloco 2 x 2 no macrobloco recebe um valor U e um valor 
V- a média dos quatro valores de pixel. O sub-bloco ainda possui quatro valores Y. O relacionamento 
entre um quadro e os macroblocos correspondentes aparece na Figura 7.15. 

Os quadros P e B também são processados em unidades de macroblocos. Intuitivamente, podemos 
ver que as informações que eles transportam para cada macrobloco capturam o movimento no vídeo; 
ou seja, elas mostram em que direção e o quanto o macrobloco se moveu em relação ao(s) quadro(s) 
anterior(es). A seguir, descrevemos como um quadro B é usado para reconstruir um quadro durante a 
descompressão; os quadros P são tratados de modo semelhante, exceto que dependem apenas de um 
quadro de referência, em vez de dois. 

Antes de chegarmos aos detalhes de como um quadro B é descomprimido, observe primeiro que 
cada macrobloco em um quadro B não é necessariamente definido em relação a um quadro anterior e 
seguinte, como sugerimos anteriormente, mas pode simplesmente ser especificado em relação a apenas 
um ou outro. De fato, determinado macrobloco em um quadro B pode usar a mesma intracodificação 
usada em um quadro I. Essa flexibilidade existe porque, se a imagem em movimento estiver mudando 
muito rapidamente, então, às vezes, faz sentido usar a codificação intraimagem, em vez de uma codi- 
ficação prevista relativa a uma imagem anterior ou posterior. Assim, cada macrobloco em um quadro 
B inclui um campo de tipo, que indica qual codificação é usada para esse macrobloco. Todavia, na 
discussão a seguir, consideramos apenas o caso geral em que o macrobloco usa a codificação prevista 
bidirecional. 

Nesse caso, cada macrobloco em um quadro B é representado por uma quádrupla: (1) uma coor- 
denada para o macrobloco no quadro, (2) um vetor de movimento relativo ao quadro de referência 
anterior, (3) um vetor de movimento relativo ao quadro de referência seguinte, e (4) um delta (6) para 
cada pixel no macrobloco (ou seja, o quanto cada pixel mudou em relação aos dois pixels de referência). 
Para cada pixel no macrobloco, a primeira tarefa é encontrar o pixel de referência correspondente nos 
quadros de referência passado e futuro. Isso é feito usando os dois vetores de movimento associados 
ao macrobloco. Depois, o delta para o pixel é acrescentado à média desses dois pixels de referência. 
Mais exatamente, se considerarmos F, e Fcomo indicando os quadros de referência passado e futuro, 
respectivamente, e os vetores de movimento passado /futuro forem dados por (x,, Yp) e (Xp yp, então o 
pixel na coordenada (x,y) do quadro corrente (indicado por F,) é calculado como 


Fel, y) = (F (x+x,,yY+y,) + Fltx,y+y,)/2+600,7) 


onde ô é o delta para o pixel, conforme especificado no quadro B. Esses deltas são codificados da mesma 
maneira que os pixels nos quadros I. Ou seja, eles passam pela DCT e depois são quantizados. Como 
os deltas normalmente são pequenos, a maior parte dos coeficientes da DCT é 0 após a quantização; 
assim, eles podem ser comprimidos de modo eficaz. 

Pela discussão anterior, deve ter ficado bem claro o modo como a codificação seria realizada, com 
uma exceção. Ao gerar um quadro B ou P durante a compressão, o MPEG precisa decidir onde colocar 
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os macroblocos. Lembre-se que cada macrobloco em um quadro P por exemplo, é definido em relação a 
um macrobloco em um quadro I, mas que o macrobloco no quadro P não precisa estar na mesma parte 
do quadro que o macrobloco correspondente no quadro I — a diferença na posição é dada pelo vetor 
de movimento. Você gostaria de utilizar um vetor de movimento que torne o macrobloco no quadro P 
o mais semelhante possível ao macrobloco correspondente no quadro I, de modo que os deltas para 
esse macrobloco possam ser os menores possíveis. Isso significa que você precisa descobrir de onde os 
objetos na figura se moveram de um quadro para o outro. Esse é o problema da estimativa de movimento, 
e várias técnicas (heurísticas) para solucionar esse problema são conhecidas. (Discutimos os artigos 
que consideram esse problema na seção “Leitura adicional”, ao final deste capítulo.) A dificuldade desse 
problema é um dos motivos para a codificação MPEG levar muito mais tempo do que a decodificação, 
usando hardware equivalente. O MPEG não especifica qualquer técnica específica; ele só define o 
formato para a codificação dessa informação nos quadros B e P e o algoritmo para reconstruir o pixel 
durante a descompressão, como indicamos anteriormente. 


Eficiência e desempenho 

O MPEG normalmente atinge uma taxa de compressão de 90 para 1, embora também sejam possíveis 
taxas de até 150 para 1. Em termos de tipos de quadros individuais, podemos esperar uma taxa de 
compressão de aproximadamente 30 para 1 para os quadros I (isso é coerente com as taxas alcançadas 
usando JPEG quando cores de 24 bits são reduzidas inicialmente para cores de 8 bits), enquanto as 
taxas de compressão de quadros P e Bnormalmente são de três a cinco vezes menores que as taxas para 
o quadro I. Sem primeiro reduzir os 24 bits de cor para 8 bits, a compressão alcançada com o MPEG 
normalmente fica entre 30 para 1 e 50 para 1. 

O MPEG envolve um cálculo extenso. No lado da compressão, ele normalmente é feito off-line, o que 
não é um problema para a preparação de filmes para um serviço de vídeo sob demanda. Hoje em dia, o 
vídeo pode ser comprimido em tempo real por meio de hardware, mas as implementações de software 
estão rapidamente chegando a esse ponto. No lado da descompressão, já existem placas de vídeo MPEG 
de baixo custo, mas elas fazem pouco mais do que a busca de cores YUV, que felizmente é a parte mais 
dispendiosa do processo. A maior parte da decodificação MPEG real é feita em software. Nos últimos 
anos, os processadores têm se tornado rápidos o suficiente para atingir uma velocidade de 30 quadros 
por segundo ao decodificar fluxos MPEG puramente em software — os processadores modernos podem 
até mesmo decodificar fluxos MPEG de vídeo de alta definição (HDTV). 


Outros padrões de codificação de vídeo 

Concluímos observando que o MPEG não é o único padrão disponível para a codificação do vídeo. 
Por exemplo, a ITU-T também definiu a série H para codificação de dados multimídia em tempo real. 
Em geral, a série H inclui padrões para vídeo, áudio, controle e multiplexação (por exemplo, combinar 
áudio, vídeo e dados em um único fluxo de bits). Dentro da série, o H.261 e o H.263 são os padrões de 
codificação de vídeo de primeira e segunda gerações. Ao contrário das primeiras versões do MPEG, 
que são voltadas para taxas de transmissão de bits na ordem de 1,5 Mbps, o H.261 e o H.263 trabalham 
com velocidades mais baixas. Projetados para os padrões de Rede Digital de Serviços Integrados (ISDN 
— Integrated Services Digital Network), eles dão suporte a vídeo por enlaces com largura de banda dis- 
ponível em incrementos de 64 Kbps. A princípio, tanto o H.261 quanto o H.263 se parecem muito com 
o MPEG. Eles usam DCT, quantização e compressão interquadros. As diferenças entre o H.261/H.263 
e o MPEG estão nos detalhes. Na verdade, o padrão H.264 mais novo também faz parte do padrão 
MPEG-4. À medida que o vídeo é suportado em cada vez mais dispositivos, variando desde dispositivos 
com tela pequena conectados por enlaces de celular com baixa largura de banda até TVs de tela grande 
conectadas a enlaces de fibra com alta largura de banda, provavelmente haverá mais demanda para 
inovação e novos padrões nessa área. 


7.2.4 Transmissão MPEG por uma rede 


Conforme sugerimos anteriormente neste capítulo, o MPEG e o JPEG não são apenas padrões de com- 
pressão, mas também definições do formato de vídeo e imagens, respectivamente. Focalizando o MPEG, 
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a primeira coisa a ter em mente é que ele define o formato de um fluxo de vídeo; ele não especifica 
como esse fluxo é quebrado em pacotes para serem transferidos pela rede. Assim, o MPEG pode ser 
usado para vídeos armazenados em disco, bem como para vídeos transmitidos por uma conexão de 
rede orientada a fluxo, como aquela fornecida pelo TCP. Mais adiante, veremos como você poderia 
empacotar um fluxo MPEG. 

O formato MPEG é um dos mais complicados de todos os protocolos discutidos neste livro. Essa 
complicação vem de um desejo de dar ao algoritmo de codificação todo grau de liberdade possível no 
modo como ele codifica determinado fluxo de vídeo. Ela também provém da evolução do padrão com 
o tempo (por exemplo, MPEG-1, MPEG-2, MPEG-4). O que descrevemos a seguir é chamado perfil 
principal de um fluxo de vídeo MPEG-2. Você pode pensar em um perfil MPEG como sendo semelhante a 
uma “versão”, exceto que o perfil não é especificado explicitamente em um cabeçalho MPEG; o receptor 
precisa deduzir o perfil a partir da combinação dos campos de cabeçalho que ele encontra. 

Um fluxo MPEG-2 do perfil principal possui uma estrutura aninhada, como ilustra a Figura 7.16. 
(Tenha em mente que essa figura esconde muitos detalhes complicados.) No nível mais externo, o 
vídeo contém uma sequência de grupos de imagens (GOP — Groups Of Pictures) separados por um 
CabSeq. A sequência é terminada por um CódigoFimSeg (0xb7). O CabSeg que precede cada GOP 
especifica — entre outras coisas — o tamanho de cada imagem (quadro) no GOP (medido como pixels e 
macroblocos), o período interimagem (medido em ps) e duas matrizes de quantização para os macro- 
blocos dentro desse GOP: uma para macroblocos intracodificados (blocos I) e outra para macroblocos 
intercodificados (blocos B e P). Como essa informação é dada para cada GOP — e não uma vez para o 
fluxo de vídeo inteiro, como você poderia esperar — é possível trocar a tabela de quantização e a taxa de 
quadros nos limites de GOP no decorrer do vídeo. Isso torna possível a adaptação do fluxo de vídeo ao 
longo do tempo, conforme discutimos a seguir. 

Cada GOP é dado por um CabGOP, seguido pelo conjunto de imagens que compõem o GOP. O 
CabGOP especifica o número de imagens no GOP além das informações de sincronismo para o GOP 
(ou seja, quando o GOP deverá ser exibido, em relação ao início do vídeo). Cada imagem, por sua vez, 
é dada por um Cablmagem e um conjunto de fatias que compõem a imagem. (Uma fatia é uma região 
da imagem, por exemplo, uma linha horizontal.) O Cablmagem identifica o tipo de imagem (I, B ou P), 
além de definir uma tabela de quantização específica da imagem. O CabFatia indica a posição vertical 
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FIGURA 7.16 Formato de um fluxo de vídeo comprimido com MPEG. 
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da fatia, além de dar outra oportunidade para mudar a tabela de quantização — dessa vez, por um fator 
de escala constante, ao invés de dar uma tabela totalmente nova. Depois disso, o CabFatia é seguido 
por uma sequência de macroblocos. Finalmente, cada macrobloco inclui um cabeçalho que especifica 
o endereço do bloco dentro da imagem, junto com os dados para os seis blocos dentro do macrobloco: 
um para o componente U, um para o componente V e quatro para o componente Y. (Lembre-se que o 
componente Y é 16 x 16, enquanto os componentes U e V são 8x8.) 

Deve ficar claro que um dos pontos fortes do formato MPEG é que ele dá ao codificador uma opor- 
tunidade para alterar a codificação ao longo do tempo. Ele pode mudar a taxa de quadros, a resolução, 
a combinação de tipos de quadro que definem um GOP a tabela de quantização e a codificação usada 
para macroblocos individuais. Por conseguinte, é possível adaptar a taxa em que um vídeo é transmitido 
por uma rede, equilibrando a qualidade da imagem em função da largura de banda da rede. O modo 
exato como o protocolo de rede poderia explorar essa capacidade de adaptação atualmente é assunto 
de intensa pesquisa (veja a nota em destaque). 

Outro aspecto interessante do envio de um fluxo MPEG pela rede é como exatamente o fluxo é 
dividido em pacotes. Se enviado por uma conexão TCP o empacotamento não é um problema; o TCP 
decide quando possui bytes suficientes para enviar o próximo datagrama IP. Porém, ao usar o vídeo 
interativamente, é raro transmiti-lo sobre TCP pois o TCP tem vários recursos que não são adequados 
para aplicações altamente sensíveis à latência (como mudanças bruscas de taxa após uma perda de 
pacote e retransmissão de pacotes perdidos). Se estivermos transmitindo vídeo usando UDP digamos, 
então faz sentido dividir o fluxo em pontos cuidadosamente selecionados, por exemplo, nos limites 
de macrobloco. Isso porque gostaríamos de confinar os efeitos de uma perda de pacotes a um único 
macrobloco, ao invés de danificar vários macroblocos com uma única perda. Esse é um exemplo de 
enquadramento no nível da aplicação, que é discutido na Seção 5.4. 





CODIFICAÇÃO ADAPTATIVA DE VÍDEO 


Já observamos que a codificação de vídeo usando MPEG permite fazer escolhas entre a largura de banda 
consumida e a qualidade da imagem. Por outro lado, deve estar claro que a largura de banda da saída de 
um algoritmo de compressão de vídeo operando em certo nível de qualidade, em geral, não será constante, 
mas variará com o tempo, dependendo da quantidade de detalhes e movimentos no fluxo de vídeo. Esses 
fatos levantam algumas questões interessantes sobre como projetar um sistema para transportar o vídeo 
comprimido por uma rede de pacotes. 

Suponha que tenhamos um codec de vídeo que gere um fluxo de vídeo comprimido a uma taxa média 
de R bps, mas ocasionalmente aumenta esta taxa para 3R bps. Poderíamos potencialmente transmitir o 
fluxo de vídeo por um tubo com largura de banda fixa (por exemplo, uma linha alugada ou circuito CBR) 
de capacidade R, contanto que passássemos o fluxo de vídeo por um “buffer de suavização”, que reduz as 
flutuações na taxa de transmissão. Agora, em algum ponto o buffer de suavização poderia se encher além de 
um nível aceitável, talvez devido a uma longa sequência de ações em um filme, causando um longo período 
em que a taxa de saída do codec é elevada. Nesse ponto, poderíamos aumentar a quantidade de compressão 
por um tempo, reduzindo assim a taxa de dados (e a qualidade da imagem), e permitindo que o buffer 
de suavização reduza seu conteúdo. Quando ele ficasse quase vazio, poderíamos aumentar novamente a 
qualidade da codificação. 

Poderíamos muito bem fazer a mesma coisa em uma rede de comutação de pacotes, mas sem um 
buffer de suavização. Vamos supor que temos alguma maneira de medir a quantidade de capacidade livre 
e o nível de congestionamento ao longo de um percurso, por exemplo, usando um algoritmo de controle 
de congestionamento baseado em equação, como aqueles descritos na Seção 6.5.4. Como a largura de 
banda disponível flutua, podemos alimentar essa informação no codec para que ele ajuste seus parâmetros 
de codificação de modo a operar mais lentamente durante o congestionamento e transmitir mais 
agressivamente (com uma qualidade de imagem maior) quando a rede estiver ociosa. Isso é semelhante ao 
comportamento do TCP exceto que, no caso do vídeo, estamos na realidade modificando a quantidade total 
de dados enviados, ao invés do tempo gasto para enviar uma quantidade de dados fixa, pois não queremos 
introduzir atraso em uma aplicação de vídeo. 
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Um problema interessante surge se estivermos enviando um fluxo de vídeo por multicast a muitos 
receptores. Como escolhemos a taxa correta para cada receptor, já que eles podem estar experimentando 
níveis de congestionamento muito diferentes? Uma solução inteligente para esse problema é dividir o vídeo 
transmitido em “camadas”. A primeira camada teria o nível básico de detalhe, necessário para ver algum tipo 
de imagem útil, com cada camada subsequente aumentando os detalhes, consistindo em informações de 
frequência mais alta. Cada camada pode então ser enviada a um endereço de grupo de multicast diferente, 
e cada receptor pode decidir a quantas camadas deseja se juntar. Se o receptor A estiver experimentando 
um intenso congestionamento, ele poderá se juntar apenas ao grupo de multicast transmitindo a camada 
básica, enquanto o receptor B poderia se juntar a todas as camadas. O receptor A poderia periodicamente 
tentar se juntar à próxima camada de detalhe para ver se há mais largura de banda à sua disposição. Essa 
técnica é conhecida como multicast em camadas controlado pelo receptor (RLM - Receiver-driven Layered 
Multicast). Um problema de pesquisa interessante é como criar o conjunto certo de incentivos para fazer 
com que um receptor se junte ao número apropriado de grupos, em vez de simplesmente se juntar a todos 
eles, pois isso causaria congestionamento desnecessário na rede. 





O empacotamento do fluxo é apenas o primeiro problema quando se envia vídeo comprimido 
com MPEG por uma rede. A próxima complicação é lidar com a perda de pacotes. Por um lado, se um 
quadro B for descartado pela rede, então é possível simplesmente reproduzir o quadro anterior sem 
comprometer seriamente o vídeo; 1 quadro dentre os 30 não é grande coisa. Por outro lado, um quadro 
I perdido resultaria na perda de vários quadros do vídeo. Embora você pudesse retransmitir o quadro I 
que faltou, o atraso resultante provavelmente não seria aceitável em uma videoconferência em tempo 
real. Uma solução para esse problema seria usar técnicas de Serviços Diferenciados, descritas na Seção 
6.5.3, para marcar os pacotes contendo quadros I com uma probabilidade de descarte inferior à dos 
outros pacotes. 

Uma observação final é que o modo como você escolhe codificar o vídeo depende de mais do que 
apenas a largura de banda disponível na rede. Isso também depende das restrições de latência da apli- 
cação. Mais uma vez, uma aplicação interativa (como uma videoconferência) exige latências pequenas. 
O fator crítico é a combinação de quadros I, Pe Bno GOP Considere o seguinte GOP: 


IBBBBPBBBBI 


O problema que esse GOP causa em uma aplicação de videoconferência é que o emissor precisa 
adiar a transmissão dos quatro quadros B até que o P ou o I seguinte esteja disponível. Isso porque cada 
quadro B depende do quadro P ou I subsequente. Se o vídeo estiver sendo reproduzido a 15 quadros por 
segundo (ou seja, um quadro a cada 67 ms), isso significa que o primeiro quadro B é atrasado em 4 x 67 
ms, que é mais de um quarto de segundo. Esse atraso é adicionado a qualquer atraso de propagação 
imposto pela rede. Um quarto de segundo é muito mais do que o patamar de 100 ms que os humanos 
são capazes de perceber. É por esse motivo que muitas aplicações de videoconferência codificam o 
vídeo usando JPEG, o que normalmente é chamado de motion-JPEG. (O Motion-JPEG também ataca 
o problema do descarte de um quadro de referência, pois todos os quadros são independentes.) Porém, 
observe que uma codificação interquadros que dependa somente dos quadros anteriores, e não dos 
quadros seguintes, não ocasiona esse problema. Assim, um GOP 


IPPPPI 
funcionaria muito bem para uma videoconferência interativa. 


7.2.5 Compressão de áudio (MP3) 


O MPEG não apenas define como o vídeo é comprimido, mas também define um padrão para com- 
pressão de áudio. Esse padrão pode ser usado para comprimir a parte de áudio de um filme (caso em 
que o padrão MPEG define como o áudio comprimido é intercalado com o vídeo comprimido em um 
único fluxo MPEG), ou então pode ser usado para comprimir áudio independente (por exemplo, 
um CD de áudio). 
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Para entender a compressão de áudio, precisamos começar com os dados. O áudio com qualidade de 
CD, que é a representação digital de fato para áudio de alta qualidade, é amostrado a uma taxa de 44,1 
KHz (ou seja, uma amostra é coletada aproximadamente uma vez a cada 23 us). Cada amostra contém 
16 bits, o que significa que um fluxo de áudio estéreo (2 canais) resulta em uma taxa de bits de: 


2 x 44,1 x 1000 x 16 = 1,41Mbps 


Em comparação, a voz com qualidade de telefone é amostrada a uma taxa de 8 KHz, com amostras 
de 8 bits, resultando em uma taxa de bits de 64 Kbps, o que, não coincidentemente, correspondente à 
velocidade de um enlace ISDN. 

Claramente, alguma quantidade de compressão será necessária para transmitir o áudio com qua- 
lidade de CD, digamos, pela capacidade de 128 Kbps de um par de linhas ISDN para dados/voz. Para 
piorar as coisas ainda mais, o sobrecusto com sincronismo e correção de erros exige que 49 bits sejam 
usados para codificar cada amostra de 16 bits, resultando em uma taxa de bits real de: 


49/16 x 1,41Mbps = 4,32 Mbps 


O MPEG resolve essa necessidade por meio da definição de três níveis de compressão, conforme 
enumeração mostrada na Tabela 7.2. Desses, o Nível III, que é mais conhecido como MP3, é o mais 
utilizado. 

Para conseguir essas taxas de compressão, o MP3 usa técnicas que são semelhantes àquelas utili- 
zadas pelo MPEG para comprimir o vídeo. Primeiro, ele divide o fluxo de áudio em algum número de 
subfaixas de frequência, mais ou menos semelhante ao modo como o MPEG processa os componentes 
Y, U e V de um fluxo de vídeo separadamente. Em seguida, cada subfaixa é dividida em uma sequência 
de blocos, que são semelhantes aos macroblocos do MPEG, exceto que eles variam em tamanho de 
64 a 1024 amostras. (O algoritmo de codificação pode fazer o tamanho do bloco variar, dependendo 
de certos efeitos de distorção que estão fora do escopo da nossa discussão.) Finalmente, cada bloco é 
transformado usando um algoritmo DCT modificado, quantizado e codificado usando codificação de 
Huffman, assim como para o vídeo MPEG. 

O truque do MP3 está em quantas subfaixas ele decide usar e quantos bits ele aloca a cada subfaixa, 
lembrando que ele está tentando produzir a maior qualidade de áudio possível para a taxa de bits alvo. 
O modo exato como essa alocação é feita é controlado por modelos psicoacústicos, que estão além do 
escopo deste livro, mas, para ilustrar a ideia, considere que faz sentido alocar mais bits para subfaixas 
de frequência baixa quando se comprime uma voz masculina e mais bits para subfaixas de frequência 
alta quando se comprime uma voz feminina. Operacionalmente, para alcançar o efeito desejado, o MP3 
muda dinamicamente as tabelas de quantização usadas para cada subfaixa. 

Uma vez comprimidas, as subfaixas são empacotadas em quadros de tamanho fixo, e um cabeçalho 
é anexado a eles. Esse cabeçalho inclui informações de sincronismo, além de informações de alocação 
de bits necessárias pelo decodificador para determinar quantos bits foram usados para codificar cada 
subfaixa. Como dissemos, esses quadros de áudio podem então ser intercalados com quadros de vídeo, 
para formar um fluxo MPEG completo. Uma nota interessante é que, embora o descarte de quadros B 
na rede possa funcionar, caso ocorra congestionamento, a experiência nos ensina que não é uma boa 
ideia descartar quadros de áudio, porque os usuários estão mais dispostos a tolerar vídeo ruim do que 
áudio ruim. 


Tabela 7.2 Taxas de compressão do MP3 





Codificação Taxas de bits Fator de compressão 
Nível | 384 kbps 4 
Nível II 192 kbps 8 


Nível III 128 kbps 12 
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7.3 Resumo 


Este capítulo descreveu como os dados da aplicação são codificados em pacotes da rede. Diferente dos 
protocolos descritos anteriormente neste livro, que você pode imaginar como processando mensagens, 
essas transformações processam dados. Os tipos de dados multimídia, como vídeo, imagens e áudio, 
estão cada vez mais impulsionando os desenvolvimentos nessa área. 

A primeira questão é a formatação de apresentação, onde o problema é formatar os diferentes tipos 
de dados sobre os quais os programas de aplicação operam, de modo que eles possam ser transmitidos 
por uma rede e interpertados corretamente pelo receptor. Tipos de dados como inteiros, números em 
ponto flutuante, cadeias de caracteres, vetores e estruturas devem ser codificados de alguma forma in- 
teligível. Isso envolve traduzir entre esquemas de ordenação de bytes de máquina e de rede e serializar 
estruturas de dados compostas. Esboçamos o espaço de projetos para a formatação de apresentação 
e discutimos quatro mecanismos específicos que se localizam em diferentes pontos nesse espaço de 
projetos: XDR, ASN.], NDR e a cada vez mais importante XML. 

A segunda questão é a compressão, que trata da redução da largura de banda necessária para trans- 
mitir diferentes tipos de dados. Os algoritmos de compressão podem ser sem perdas ou com perdas; 
os algoritmos com perdas são os mais apropriados para dados de imagem e vídeo. JPEG, MPEG e MP3 
são exemplos de protocolos de compressão de dados com perdas para imagens paradas, vídeo e áudio, 
respectivamente. Técnicas de compressão e formatos de codificação, como os da família MPEG de 
padrões, continuam a evoluir para atender à demanda por qualidade mais alta dentro dos limites da 
largura de banda disponível. 


E E O que vem em seguida: vídeo por toda parte E 


Não é preciso enfatizar que o vídeo, atualmente, é o principal componente do tráfego na Internet, 
com a capacidade de se adaptar aos três principais tipos de telas — entrega de dados a aparelhos de 
TV, computadores e telefones celulares —, (abordagem conhecida como three-screen) sendo um objeto 
prioritário dos setores de computação, comunicação e entretenimento. 

Isso levanta uma série de questões interessantes. Uma é o impacto que todo esse vídeo terá 
sobre a largura de banda exigida para a Internet. Ainda estamos longe de ter capacidade implantada 
suficiente na Internet para transmitir vídeo de entretenimento para todos os que assistem TV ou 
alugam DVDs hoje. Isto não apenas aumenta a demanda por maior capacidade de rede, mas novas 
arquiteturas de rede com nomes como “rede centrada no conteúdo” estão sendo propostas. 

Diretamente mais relevante ao material deste capítulo é a necessidade de convergência com relação aos 
formatos de codificação e apresentação de vídeo nesse novo ambiente de vídeo por toda a parte. Como um 
exemplo dos desafios nessa área, considere o fato de que três das maiores empresas que atuam no ramo 
de streaming de vídeo (Microsoft®, Adobe® e Apple”) desenvolveram, cada uma, diferentes protocolos 
para fazer streaming de vídeo de sites Web para navegadores. Os usuários em sua maior parte contornam 
essas incompatibilidades hoje instalando plug-ins apropriados em seus navegadores, mas a situação fica 
decididamente mais confusa em dispositivos menos flexíveis, como telefones móveis. Com o surgimento 
detelevisores com acesso à Internet e conversores de TV Digital (conhecidos como set-top-boxes), formatos de 
vídeo incompatíveis provavelmente continuarão a ser uma fonte de irritação para os consumidores. 

O padrão emergente da HTML 5 tentou garantir que, pelo menos, um codec e formato de vídeo 
comum seja suportado por todos os navegadores, pelo menos como um denominador comum, mas 
esse processo até aqui não conseguiu convergir. Questões de patente fizerem com que alguns dos parti- 
cipantes no processo de padronização hesitassem em endossar qualquer formato por medo de que um 
detentor de patente (até aqui desconhecido) decida ser manifestar quando sua patente for infringida. 

Outra questão que aparecerá em cena quando o vídeo via IP se tornar onipresente refere-se à 
facilidade de configuração e gerenciamento dos dispositivos IP Embora alguns dos usuários da 
Internet atualmente se sintam confortáveis em configurar parâmetros de rede (meu ISP usa DHCP? 
PPoE?), é improvável que o comprador comum de uma televisão queira aprender a configurar algo 
mais complexo do que o botão de mudança de canal. A configuração “plug-and-play” de dispositivos 
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IP continua a ser um objetivo importante, assim como a capacidade de resolver problemas com esses 
dispositivos sem ser um especialista em redes. Isso faz parte do problema maior do gerenciamento 
de dispositivos domésticos, que agora emergiu como um dos tópicos quentes no uso de redes. 


Leitura adicional 


Nossa lista de leitura recomendada para este capítulo inclui dois artigos que dão uma visão geral dos padrões JPEG e MPEG, 
respectivamente. Sua contribuição principal está na explicação de vários fatores que modelaram os padrões. Também 
recomendamos o artigo sobre multicast em camadas controlado pelo receptor, como um excelente exemplo de uma técnica 
de projeto de sistemas, abrangendo as questões de multicast, controle de congestionamento e codificação de vídeo. 
Wallace, G. K. The JPEG still picture compression standard. Communications of the ACM, v. 34, n. 1, p. 30-44, abril de 1991. 
Le Gall, D. MPEG: a video compression standard for multimedia applications. Communications of the ACM, v. 34, n. 1, 
p. 46-58, abril de 1991. 
McCanne, S.; Jacobson, V.; Vetterli, M. Receiver-driven layered multicast. Proceedings of the SIGCOMM '96 Symposium, 
p. 117-30, setembro de 1996. 


Infelizmente, não existe um artigo isolado que dê um tratamento abrangente da formatação de apre- 
sentação. Além das especificações XDR, ASN.I/BER e NDR (ver Eisler [Eis06] das recomendações do 
CCITT [CCITT92a], [CCITT92b] e da Open Software Foundation [OSF94]), três outros artigos abordam 
assuntos relacionados à formatação de apresentação: os de O'Malley et al. [OPM94], Lin [Lin93] e Chen 
et al. [CLNZ89]. Todos os três discutem questões relacionadas ao desempenho. 

Sobre o assunto de compressão, um bom local para começar é com a codificação de Huffman, que foi 
definida originalmente em [Huf52]. O algoritmo LZ original é apresentado em Ziv e Lempel [ZL77], e uma 
versão melhorada desse algoritmo, desenvolvida pelos mesmos autores, pode ser encontrada em [ZL78]. 
Esses dois artigos são de natureza teórica. O trabalho que trouxe a técnica LZ para a prática geral pode 
ser encontrado em Welch [Wel84]. Para uma visão geral mais completa do tópico de compressão, o artigo 
de Nelson [Nel92] é recomendado. Existem muitos livros sobre multimídia que abordam a compressão. 
Recomendamos Witten et al. [WMB99], que possui uma proporção extremamente alta entre ciência e 
moda, e Buford [Buf94], que é uma coleção de capítulos resultantes da colaboração de diferentes autores 
que abrangem os tópicos de multimídia. O livro de Weise e Weynand [WW07] aborda quase todo aspecto 
do vídeo, incluindo a compressão e muitos outros tópicos. Para obter uma descrição abrangente do padrão 
MPEG, consulte Mitchell et al. [MPFL96]. Para obter uma descrição do MP3, consulte Noll [Nol97]. 

Finalmente, recomendamos as seguintes referências vivas: 


e  http://www.w3.org/TR/REC-xml/: A especificação XML mais recente. 
e hitp:/mpeg.chiariglione.org/: Página web do Motion Picture Experts Group, uma fonte de grande 
parte do material sobre MPEG 


Exercícios 
1. Considere o seguinte código em C: 


ádefine MAXSTR 100 


struct data ( 
char mes[MAXSTR]; 
int dia; 
int ano; 


k 


struct empregado { 
char nome[MAXSTR]; 


int cpf; 

struct data -contratacao; 
int historico_salario[5]; 
int numero_aumentos; 


k 


static struct data data0 = ((DECEMBER", 2, 1998); 

static struct data data1 = ((JANUARY”, 7, 2002); 

static struct empregado empregadoO = (“RICHARD”, 4376, &data0,(80000, 
85000, 90000, 0, 0}, 2}; 

static struct empregado empregado1 = (“MARY”, 4377, &data1, (90000, 
150000, 0, 0, 0}, 1); 
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onde numero aumentos + 1 corresponde ao número de entradas válidas no vetor historico . 
salario. Mostre a representação na rede para empregado0O que é gerada pela XDR. 


- Mostre a representação na rede de empregado1 do problema anterior que é gerada pela XDR. 


Para as estruturas de dados do exercício anterior, forneça a rotina XDR que codifica/decodifica 
essas estruturas. Se você tiver um programa de XDR disponível, execute essa rotina e meça 
quanto tempo é necessário para codificar e decodificar uma instância de exemplo da estrutura 
empregado. 

Usando funções de biblioteca como htonl e bcopy do Unix ou CopyMemory do Windows, 
implemente uma rotina que gere a mesma representação de rede das estruturas dadas 

no Exercício 1 como a XDR gera. Se possível, compare o desempenho do seu codificador/ 
decodificador “manual” com as rotinas XDR correspondentes. 

Use XDR e htonl para codificar um vetor de inteiros com 1.000 elementos. Meça e compare o 
desempenho de cada um. Como estes se comparam com um laço simples que lê e escreve um 
vetor de inteiros com 1.000 elementos? Realize a experiência em um computador para o qual a 
ordem de bytes nativa é igual à ordem de bytes da rede, bem como em um computador para o 
qual a ordem de bytes nativa e a ordem de bytes da rede são diferentes. 

Escreva sua própria implementação do htonl. Usando seu próprio htonl e (caso um equipamento 
de hardware little-endian esteja disponível) a versão da biblioteca padrão, execute experiências 
apropriadas para determinar quanto tempo a mais é necessário para inverter os bytes de inteiros 
versus simplesmente copiá-los. 

Mostre a codificação ASN. 1 para os três inteiros a seguir. Observe que os inteiros ASN. 1, 

como aqueles na XDR, possuem 32 bits de extensão. 

a. 101 

b. 10.120 

c. 16.909.060 


. Mostre a codificação ASN. 1 para os três inteiros a seguir. Observe que os inteiros ASN. 1, 


como aqueles na XDR, possuem 32 bits de extensão. 

a. 15 

b. 29.496.729 

c. 58.993.458 

Mostre a representação big-endian e little-endian para os inteiros do Exercício 7. 

Mostre a representação big-endian e little-endian para os inteiros do Exercício 8. 

A XDR é usada para codificar/decodificar o cabeçalho do protocolo SunRPC ilustrado 

na Figura 5.18. A versão XDR é determinada pelo campo VersãoRPC. Que dificuldade 

em potencial isso apresenta? Seria possível que uma nova versão da XDR fosse alterada 

para operar com o formato de inteiros little-endian? 

O processo de formatação de apresentação às vezes é considerado como uma camada de 
protocolo autônoma, separada da aplicação. Se este é o caso, por que a inclusão da compressão 
de dados na camada de apresentação seria uma má ideia? 

Suponha que você tenha uma máquina com um tamanho de palavra de 36 bits. As cadeias 

de caracteres são representadas como cinco caracteres de 7 bits empacotados por palavra. 

Que problemas de apresentação nessa máquina teriam que ser resolvidos para que ela troque 
dados inteiros e cadeias de caracteres com o restante do mundo? 

Usando a linguagem de programação à sua escolha, que admita conversões automáticas de tipos 
definidas pelo usuário, defina um tipo netint e forneça conversões que permitam atribuições 

e comparações de igualdade entre ints e netints. Uma generalização dessa técnica poderia 
solucionar o problema de empacotamento de argumentos da rede? 

Diferentes arquiteturas possuem diferentes convenções sobre a ordem de bits e também a ordem 
de bytes — por exemplo, se o bit menos significativo de um byte é o bit 0 ou o bit 7. O RTC 791 
[Pos81] define (em seu Apêndice B) a ordem de bits padrão da rede. Por que, então, a ordem de 
bits não é relevante para a formatação de apresentação? 

Considere que p < 1 seja a fração de máquinas em uma rede que são big-endian; a fração 1 - p 
restante é little-endian. Suponha que escolhemos duas máquinas aleatórias e enviamos um 

int de uma para outra. Forneça o número médio de conversões da ordem de bytes necessárias 
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17. 


18. 


fr 19. 


fr 20. 


21. 


22. 


fr 23. 


para uma rede cuja ordem de bytes seja big-endian e para uma rede do tipo receptor-acerta, 

considerando p = 0,1, p= 0,5 e p=0,9. (Dica: A probabilidade de que as duas extremidades sejam 

big-endian é p?; a probabilidade de que as duas extremidades usem diferentes ordenações de 

bytes é 2p(l - p). 

Descreva uma representação para documentos XML que seria mais compacta e mais eficiente de 

processar do que texto XML. 

Faça experimentos com um utilitário de compressão (por exemplo, compress, gzip ou pkzip). 

Que taxas de compressão você consegue? Veja se você é capaz de gerar arquivos de dados para os 

quais consiga taxas de compressão de 5:1 ou 10:1. 

Suponha que um arquivo contenha as letras a,b,c e d. Nominalmente, exigimos 2 bits por letra 

para armazenar tal arquivo. 

a. Suponha que a letra a ocorra 50% do tempo, b ocorra 30% do tempo e c e d ocorram cada uma 
10% do tempo. Mostre uma codificação de cada letra como uma cadeia de bits que forneça 
compressão ideal. (Dica: Use um único bit para a.) 

b. Qual é a porcentagem de compressão que você consegue no item acima? (Este valor 
corresponde à média das porcentagens de compressão alcançadas para cada letra, com o 
peso definido pela frequência da letra.) 

c. Repita o processo anterior, supondo que a e b ocorram 40% do tempo cada um, que c ocorra 
15% do tempo, e que d ocorra 5% do tempo. 

Suponha que temos uma função de compressão c, que transforme uma cadeia de bits s em uma 

cadeia comprimida c(s). 

a. Mostre que, para qualquer inteiro N, deve haver uma cadeia s de tamanho N para a qual 
tamanho(c(s)) > N; ou seja, nenhuma compressão efetiva é feita. 

b. Comprima alguns arquivos já comprimidos (tente comprimir com o mesmo utilitário várias 
vezes seguidas). O que acontece com o tamanho do arquivo? 

c. Dada uma função de compressão c como aquela do item (a), forneça uma função c’ tal que, 
para todas as cadeias de bits s, tamanho(c’(s)) < min(tamanho(c(s)), tamanho (s)) + 1; ou seja, 
na pior das hipóteses, a compressão com c expande o tamanho em apenas 1 bit. 

Crie um algoritmo de codificação por carreira que exija apenas um único byte para representar 

os símbolos não repetidos. 

Escreva um programa para construir um dicionário de todas as “palavras”, definidas como 

cadeias de caracteres consecutivos não contendo espaços em branco entre eles, de um 

determinado arquivo de texto. Poderíamos, então, comprimir o arquivo (ignorando a perda da 
informação de espaços em branco) representando cada palavra como um índice no dicionário. 

Obtenha o arquivo rfc791.txt contendo [Pos81] e execute seu programa passando este arquivo 

como entrada. Forneça o tamanho do arquivo comprimido supondo primeiro que cada palavra 

é codificada com 12 bits (isso deverá ser suficiente), e depois que as 128 palavras mais comuns 

são codificadas com 8 bits e o restante com 13 bits. Suponha que o próprio dicionário possa ser 

armazenado usando, para cada palavra, tamanho(palavra) + 1 bytes. 

A transformada discreta do cosseno unidimensional é semelhante à transformada 

bidimensional, exceto que removemos a segunda variável (j ou y) e o segundo fator do cosseno. 

Também removemos, do DCT inverso apenas, o coeficiente 1/V2N inicial. Implemente esta 

operação e sua inversa para N=8 (uma planilha será suficiente para fazer isso, embora uma 

linguagem com suporte a matrizes possa ser melhor) e responda: 

a. Se os dados de entrada forem (1, 2, 3, 5, 5, 3, 2, 1), que coeficientes da DCT ficam próximos de 0? 

b. Se os dados forem (1, 2, 3, 4, 5, 6, 7, 8), quantos coeficientes de DCT devemos manter para 
que, após a DCT inversa, os valores estejam todos dentro de 1% de seus valores originais? 

E 10%? Suponha que coeficientes de DCT removidos sejam substituídos por 0s. 

c. Suponha que s; para 1 < i <8, seja a sequência de entrada consistindo em um 1 na posição 
i e 0 na posição j, j+ i. Suponha que apliquemos a DCT a s; zeremos os três últimos 
coeficientes e depois apliquemos a DCT inversa. Qual valor dei, 1 < i < 8, resulta no menor 
erro na i-ésima posição do resultado? Qual resulta no maior erro? 
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Compare o tamanho de uma imagem toda branca no formato JPEG com uma imagem 

fotográfica “típica” das mesmas dimensões. Em que estágio ou estágios do processo 

de compressão JPEG a imagem branca torna-se menor que a imagem fotográfica? 

Para os três exercícios a seguir, os utilitários cjpeg e djpeg podem ser úteis e podem ser obtidos 

em http://www .ijg.org/. Outros utilitários de conversão JPEG também podem ser usados. 

Para a criação e análise manual de arquivos gráficos, o formato portátil de tons de cinza pgm 

é recomendado; no Unix, consulte as páginas obtidas com o comando “man” para os utilitários 

pgm(5)/ppm(5). 

Crie uma imagem em tons de cinza consistindo em uma grade 8 x 8 com uma linha preta vertical 

na primeira coluna. Faça a compressão para o formato JPEG e depois faça a descompressão. 

O quão diferentes ficam os bytes resultantes na opção de qualidade padrão? Visualmente, 

como você descreveria as imprecisões introduzidas? Que opção de qualidade é suficiente 

para recuperar o arquivo com exatidão? 

Crie uma imagem em tons de cinza 8 x 8 consistindo em um texto ASCII com 64 caracteres. 

Use apenas letras minúsculas, sem espaços em branco ou pontuação. Faça a compressão para o 

formato JPEG e depois faça a descompressão. O resultado é reconhecível como sendo um texto? 

Por que a inclusão de espaços em branco pode piorar as coisas? Com a opção de qualidade 

em 100, esse seria um modo plausível de comprimir texto? 

Escreva um programa que implemente a DCT direta e inversa, usando aritmética em ponto 

flutuante. Execute o programa passando como entrada uma imagem de exemplo em tons de 

cinza. Como a DCT é sem perdas, a imagem de saída do programa deverá ser igual à entrada. 

Agora, modifique seu programa para que ele zere alguns dos componentes de frequência mais 

alta e veja como a imagem de saída é afetada. Como isso é diferente daquilo que o JPEG faz? 

Expresse DCT(0,0) em termos da média dos pixels (x,y). 

Pense a respeito de quais funções poderiam razoavelmente ser esperadas de um padrão de 

vídeo: avanço rápido, capacidades de edição, acesso aleatório e assim por diante. (Veja o artigo 

de Le Gall, “MPEG: A video compression Standard for multimedia applications”, citado na seção 

“Leitura adicional” deste capítulo, para obter outras ideias.) Explique o projeto do MPEG em 

termos desses recursos. 

Suponha que você queira implementar o avanço e retrocesso rápido para fluxos MPEG. Com 

que problemas você se depara se limitar seu mecanismo a exibir apenas quadros I? Se isso não 

for feito, então para exibir determinado quadro na sequência de avanço rápido, qual é o maior 

número de quadros na sequência original que você pode ter que decodificar? 

Use mpeg. play para reproduzir um vídeo codificado com MPEG. Experimente as opções, 

particularmente -nob e -nop, que são usadas para omitir do fluxo os quadros B e P 

respectivamente. Quais são os efeitos visíveis da omissão desses quadros? 

O programa mpeg. start pode ser usado para exibir estatísticas para fluxos de vídeo. 

Use-o para determinar, para vários fluxos: 

a. número e sequência de quadros I, Be P 

b. taxa de compressão média para o vídeo inteiro 

c. taxa de compressão média para cada tipo de quadro 

Suponha que tenhamos um vídeo com dois pontos brancos movendo-se um em direção ao outro 

a uma velocidade uniforme contra um fundo preto. Codificamos isso com MPEG. Em um quadro 

I, os dois pontos estão separados por 100 pixels; no quadro I seguinte, eles estão um sobre 

o outro. O ponto final de encontro acontece no centro de um macrobloco de 16x 16. 

a. Descreva como você poderia codificar de modo ideal a componente Y dos quadros B (ou P) 
intermediários. 

b. Agora, suponha que os pontos sejam coloridos, e que a cor muda lentamente enquanto os 
pontos se movem. Descreva qual seria a aparência da codificação dos valores U eV. 


Segurança de redes 


É algo verdadeiramente grande ter em alguém a fraqueza de um homem 
e a segurança de um deus. 
Sêneca 


E E Problema: ataques à segurança E 


As redes de computadores normalmente são um recurso compartilhado, usado por muitas 
aplicações para muitas finalidades diferentes. A Internet é um ambiente particularmente 
compartilhado, sendo usada por empresas concorrentes, governos mutuamente hostis e 
criminosos oportunistas. A menos que sejam tomadas medidas de segurança, uma conversa na 
rede ou uma aplicação distribuída poderão ser comprometidas por um adversário. 

Considere algumas ameaças ao uso seguro, por exemplo, da World Wide Web. Suponha que você 
seja um cliente usando um cartão de crédito para comprar um item de um site Web. Uma ameaça 
óbvia é que um adversário esteja escutando sua comunicação na rede, lendo suas mensagens para 
obter sua informação de cartão de crédito. Como essa escuta poderia ser realizada? Isso é trivial 
em uma rede de broadcast, como uma Ethernet, onde qualquer nó pode ser configurado para 
receber todo o tráfego de mensagens nessa rede. A comunicação sem fio pode ser monitorada sem 
qualquer conexão física. Métodos mais elaborados incluem o “grampo” e plantar software espião 
em qualquer dos nós de uma cadeia de nós envolvidos na comunicação. Somente nos casos mais 
extremos (por exemplo, segurança nacional) é que medidas sérias são tomadas para impedir esse 
monitoramento, e a Internet não é um desses casos. Porém, é possível e prático cifrar mensagens 
de modo a impedir que um adversário entenda o conteúdo da mensagem. Um protocolo que faz 
isso é considerado como oferecendo confidencialidade. Levando o conceito um passo adiante, 
ocultar a quantidade de comunicação ou o destino dela é chamado de confidencialidade de 
tráfego — pois simplesmente saber a quantidade de comunicação que está indo para determinado 
destino pode ser útil para um adversário em algumas situações. 

Mesmo com confiabilidade, ainda restam ameaças para o cliente do site Web. Um adversário que 
não consegue ler o conteúdo de sua mensagem cifrada ainda pode ser capaz de alterar alguns 
bits nela, resultando em um pedido válido, digamos, para um item completamente diferente 

ou talvez 1.000 unidades do item. Existem técnicas para detectar ou impedir essa modificação. 
Um protocolo que detecta essa modificação na mensagem oferece integridade de dados. O 
adversário poderia, como alternativa, transmitir uma cópia extra da sua mensagem em um 
ataque de repetição. Do ponto de vista do site Web, pareceria que você simplesmente fez outro 
pedido do mesmo item que pediu na primeira vez. Um protocolo que detecta repetições fornece 
originalidade. A originalidade, porém, não impediria que o adversário interceptasse seu pedido, 
esperasse por um tempo e depois o transmitisse — assim, atrasando seu pedido. O adversário 
poderia, com isso, fazer com que o item chegasse na sua porta enquanto você estivesse fora 

de casa, de férias, quando ele poderia ser facilmente roubado. Diz-se que um protocolo que 
detecta essas técnicas de atraso fornece pontualidade. A integridade de dados, a originalidade e a 
pontualidade são considerados aspectos da propriedade mais geral denominada integridade. 
Outra ameaça ao cliente acontece quando ele é direcionado, sem saber, para um site falso. Isso 
pode resultar de um ataque ao Sistema de Nomes de Domínio (DNS - Domain Name System), em 
que informações falsas são inseridas em um servidor de DNS ou no cache do serviço de nomes 
do computador do cliente. Isso ocasiona a tradução de um URL correto para um endereço IP 
incorreto — o endereço do site falso. Diz-se que um protocolo que garanta que você realmente está 
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falando com quem pretende falar oferece autenticação. Autenticação pressupõe integridade, pois 
não tem sentido dizer que uma mensagem veio de certo participante se ela não for mais a mesma 
mensagem. 

O proprietário do site pode ser atacado também. Alguns sites Web foram desfigurados; os arquivos 
que compõem o site foram acessados remotamente e modificados sem autorização. Esse é um 
problema de controle de acesso: a imposição de regras com relação a quem tem permissão para fazer 
o quê. Os sites também estão sujeitos a ataques de negação de serviço (Dos — Denial of Service), 
durante os quais os clientes legítimos não conseguem acessar o site porque ele está sobrecarregado 
de solicitações falsas. A garantia de um grau de acesso é chamada de disponibilidade. 

Além dessas questões, a Internet tem sido particularmente usada como um meio de distribuição 
de códigos maliciosos, que exploram vulnerabilidades nos sistemas finais. Worms, partes de 
código autorreplicável que se espalham pelas redes, são conhecidos há várias décadas 

e continuam a causar problemas, assim como seus parentes, os vírus, que são espalhados 

pela transmissão de arquivos infectados. As máquinas infectadas podem então ser organizadas 
em redes zumbis (botnets), que podem ser usadas para causar ainda mais prejuízo, como 

para disparar ataques de Dos. 

Embora a Internet tenha sido projetada com a redundância necessária para sobreviver a 
problemas como a interrupção de um enlace ou roteador, ela não foi projetada originalmente 
para oferecer o tipo de segurança que discutimos. Os mecanismos de segurança da Internet 
basicamente têm sido reparos. Se fosse preciso realizar um novo projeto abrangente da Internet, 
a integração da segurança provavelmente seria o fator mais importante. Essa possibilidade torna 
este capítulo ainda mais pertinente. 

Existem muitas ferramentas hoje para proteger os sistemas com acesso à rede, variando desde 
diversas formas de criptografia até dispositivos especializados, como firewalls. Este capítulo 
oferecerá uma introdução a essas ferramentas, com um foco em particular no uso de métodos 
criptográficos para melhorar a segurança na rede. Melhorar a segurança nas redes continua a ser 
um campo de rápidas mudanças e considerável esforço de pesquisa. 


8.1 Blocos de montagem criptográficos 


Apresentamos passo a passo os conceitos de segurança baseada em métodos criptográficos. O primeiro 
passo são os algoritmos criptográficos — cifras e resumos criptográficos - que são introduzidos nesta 
seção. Eles não são uma solução em si, mas blocos construtivos a partir dos quais uma solução pode ser 
montada. Os algoritmos criptográficos são parametrizados por chaves, e a Seção 8.2 trata do problema 
de distribuição das chaves. No próximo passo (Seção 8.3), descrevemos como incorporar os blocos 
construtivos criptográficos em protocolos que oferecem comunicação segura entre participantes que 
possuem as chaves corretas. Finalmente, a Seção 8.4 examina vários protocolos e sistemas de segurança 
completos atualmente em uso. 


8.1.1 Princípios de cifras 


Mecanismos criptográficos podem transformar uma mensagem de modo que ela se torne ininteligível a 
qualquer parte que não tenha o segredo de como reverter a transformação. O emissor aplica uma função 
de cifração à mensagem original em texto às claras, resultando em uma mensagem em texto cifrado, que 
é enviada pela rede, como mostra a Figura 8.1. O receptor aplica uma função secreta de decifração — o 
inverso da função de cifração — para recuperar o texto às claras original. O texto cifrado transmitido pela 
rede é ininteligível a qualquer intruso, supondo que o intruso não conheça a função de decifração. A 
transformação representada por uma função de cifração e sua função de decifração correspondente é 
chamada de cifra. 

Os criptógrafos têm sido guiados pelo princípio, enunciado originalmente em 1883, de que as funções 
de cifração e decifração devem ser parametrizadas por uma chave, e além disso que as funções devem 
ser consideradas de conhecimento público — somente a chave precisa ser secreta. Assim, o texto cifrado 
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FIGURA 8.1 Cifração e decifração de chave simétrica. 


produzido por determinada mensagem de texto às claras depende da função de cifração e da chave. 
Um motivo para esse princípio é que, se você depender da cifra ser mantida secreta, então você precisa 
aposentar a cifra (não apenas as chaves) quando acreditar que ela não é mais secreta. Isso significa 
mudanças potencialmente frequentes da cifra, o que é problemático, pois é preciso muito trabalho para 
desenvolver uma nova cifra. Além disso, uma das melhores maneiras de saber se uma cifra é segura 
é usá-la por muito tempo - se ninguém a quebrar, ela provavelmente é segura. (Felizmente, existem 
muitas pessoas que tentarão quebrar as cifras e que informarão quando tiverem sucesso, de modo que 
receber nenhuma notícia geralmente é uma boa notícia.) Assim, existe custo e risco consideráveis na 
implantação de uma nova cifra. Finalmente, parametrizar uma cifra com chaves nos oferece o que, com 
efeito, é uma grande família de cifras; trocando chaves, basicamente trocamos cifras, limitando, assim, 
a quantidade de dados que um criptanalista (uma pessoa que tem como objetivo quebrar o código) 
pode usar para tentar quebrar nossa chave/cifra e a quantidade de dados que ele poderá ler se tiver 
Sucesso. 

O requisito básico para um algoritmo de cifração é que ele transforme texto às claras em texto cifrado 
de modo que somente o destinatário alvo — aquele que detém a chave de decifração — possa recuperar 
o texto às claras. Isso significa que as mensagens cifradas não podem ser lidas por pessoas que não 
possuam a chave. 

É importante observar que, quando alguém recebe um texto cifrado, ele pode ter mais informações à 
sua disposição do que apenas o próprio texto cifrado. Por exemplo, ele pode saber que o texto às claras 
foi escrito em inglês, o que significa que a letra e ocorre com mais frequência no texto às claras do que 
qualquer outra letra; a frequência de muitas outras letras e combinações de letras comuns também 
podem ser previstas. Essa informação pode simplificar bastante a tarefa de encontrar a chave. De modo 
semelhante, ele pode conhecer algo sobre o provável conteúdo da mensagem; por exemplo, a palavra 
“login” provavelmente ocorrerá no início de uma sessão de login remoto. Isso pode permitir um ataque 
de texto às claras conhecido, que tem uma chance muito maior de sucesso do que um ataque apenas 
de texto cifrado. Melhor ainda é um ataque de texto às claras escolhido, que pode ser criado pelo envio de 
alguma informação ao emissor que você sabe que ele provavelmente transmitirá — esse tipo de coisa 
acontecia em tempos de guerra, por exemplo. 

Porém, os melhores algoritmos criptográficos podem impedir que o atacante deduza a chave mesmo 
quando o indivíduo conhece o texto às claras e o texto cifrado. Isso deixa o atacante sem escolha além 
de testar todas as chaves possíveis — a busca exaustiva, pela “força bruta”. Se as chaves têm n bits, então 
existem 2” valores possíveis para uma chave (cada um dos n bits poderia ser um 0 ou um 1). Um atacante 
poderia ter a sorte de testar o valor correto imediatamente, ou então ter que testar cada valor incorreto 
antes de finalmente testar o valor correto da chave, tendo testado todos os 2” valores possíveis; o número 
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médio de tentativas para descobrir o valor correto é a metade entre esses dois extremos, ou seja, 2”/2. 
Isso pode ser computacionalmente impraticável escolhendo um espaço de chaves suficientemente 
grande e tornando a operação de verificar uma chave razoavelmente dispendiosa. O que torna isso difícil 
é que as velocidades de computação continuam aumentando, tornando viáveis cálculos anteriormente 
inviáveis. Além disso, embora estejamos nos concentrando na segurança dos dados enquanto se movem 
pela rede — ou seja, os dados às vezes são vulneráveis por um curto período de tempo -, em geral, os 
profissionais que trabalham com segurança devem considerar a vulnerabilidade dos dados que precisam 
ser armazenados em arquivos por dezenas de anos. Isso favorece um tamanho de chave generosamente 
grande. Por outro lado, chaves maiores tornam a cifração e a decifração mais lentas. 

Amaioria das cifras são cifras de bloco; elas são projetadas para usar como entrada um bloco de texto 
às claras de certo tamanho fixo, normalmente de 64 a 128 bits. O uso de uma cifra de bloco para cifrar 
cada bloco independentemente — conhecido como cifração no modo ECB (Electronic Codebook ou Livro 
de Códigos Eletrônico) — tem o problema de que determinado valor de bloco de texto às claras sempre 
resultará no mesmo bloco de texto cifrado. Logo, valores de bloco recorrentes no texto às claras são reco- 
nhecíveis como tais no texto cifrado, tornando muito mais fácil para um criptanalista quebrar a cifra. 

Para impedir isso, as cifras de bloco sempre! são extendidas para fazer o texto cifrado para um bloco 
variar dependendo do contexto. As formas como uma cifra de bloco pode ser extendida são chamadas 
modos de operação. Um modo de operação comum é o encadeamento de blocos da cifra (CBC — Cipher 
Block Chaining), em que cada bloco de texto às claras passa pela operação de XOR com o texto cifrado 
do bloco anterior antes de ser cifrado. O resultado é que o texto cifrado de cada bloco depende em parte 
dos blocos anteriores (ou seja, do seu contexto). Como o primeiro bloco de texto às claras não tem 
um bloco anterior, ele passa pela operação de XOR com um número aleatório. Esse número aleatório, 
chamado vetor de inicialização (IV — Initialization Vector), é incluído com a série de blocos de texto 
cifrado de modo que o primeiro bloco de texto cifrado possa ser decifrado. Esse modo é ilustrado na 
Figura 8.2. Outro modo de operação é o modo de contador, em que valores sucessivos de um contador 
(por exemplo, 1, 2,3, ...) são incorporados na cifração de blocos sucessivos de texto às claras. 
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FIGURA 8.2 Encadeamento de blocos da cifra (CBC). 


!Obviamente, caso a propriedade de blocos de texto às claras idênticos resultarem no mesmo bloco de texto cifrado não for 
um problema para o cenário de aplicação alvo, o modo ECB pode ser (e, na prática, comumente é) usado. (N.T.) 





Capítulo 8 ° Segurança de redes 389 


ELSEVIER 


8.1.2 Cifras de chave simétrica 


Em uma cifra de chave simétrica, os dois participantes? em uma comunicação compartilham a 
mesma chave. Em outras palavras, se uma mensagem for cifrada usando uma chave em particular, 
a mesma chave é exigida para decifrar a mensagem. Se a cifra ilustrada na Figura 8.1 fosse uma 
cifra de chave simétrica, então as chaves de cifração e decifração seriam idênticas. As cifras de 
chave simétrica também são conhecidas como cifras de chave secreta, pois a chave compartilhada 
precisa ser conhecida apenas pelos participantes. (Logo veremos a alternativa, as cifras de chave 
pública.) 

O NIST (U.S. National Institute of Standards and Technology ou Instituto Nacional de Padrões e 
Tecnologia Americano) publicou padrões para uma série de cifras de chave simétrica. O Data Encryp- 
tion Standard (DES) foi o primeiro e resistiu ao teste do tempo porque nenhum ataque criptanalítico 
melhor do que a busca por força bruta foi descoberto. A busca por força bruta, porém, tornou-se mais 
rápida. As chaves do DES (56 bits independentes) agora são muito pequenas dadas as velocidades dos 
processadores atuais. As chaves do DES possuem 56 bits independentes (embora elas tenham 64 bits 
no total; o último bit de cada byte é um bit de paridade). Conforme observamos, na média, você teria 
que pesquisar metade do espaço de 25 chaves possíveis para encontrar a correta, gerando 2®=3,6 x 10!° 
chaves. Isso pode parecer muito, mas essa busca é altamente paralelizável, de modo que é possível usar 
tantos computadores na tarefa quanto você conseguir obter — e atualmente é fácil colocar as mãos em 
milhares de computadores (a Amazon.com os alugará para você por alguns centavos de dólar a hora, 
por exemplo). No final da década de 1990, já era possível recuperar uma chave DES após algumas 
horas. Consequentemente, o NIST atualizou o padrão DES em 1999 para indicar que o DES só deveria 
ser usado para sistemas legados. 

O NIST também padronizou a cifra DES triplo (3DES), que aproveita a resistência à criptanálise do 
DES enquanto aumenta o tamanho da chave. Uma chave 3DES tem 168 (= 3 x 56) bits independentes, e é 
usada como três chaves DES; vamos chamá-las de DES-chavel, DES-chave2 e DES-chaves3. A cifração de 
um bloco usando o 3DES é realizada primeiro cifrando o bloco com o DES, usando DES-chavel, depois 
decifrando o resultado usando o DES com DES-chave2, e finalmente cifrando o resultado usando o DES 
com DES-chave3. A decifração envolve decifrar usando DES-chave3, depois cifrar usando DES-chavez, 
e depois decifrar usando DES-chavel.º 

Embora o 3DES resolva o problema de tamanho de chave do DES, ele herda algumas deficiências. As 
implementações de software do DES/3DES são lentas, pois ele foi projetado originalmente, pela IBM, 
para implementação em hardware. Além disso, o DES/3DES usa um tamanho de bloco de 64 bits; um 
tamanho de bloco maior é mais eficiente e mais seguro. 

O 3DES foi substituído pelo Padrão Avançado de Cifração (AES — Advanced Encryption Standard), 
publicado pelo NIST em 2001. A cifra selecionada para se tornar esse padrão (com poucas e pequenas 
modificações) chamava-se originalmente Rijndael (pronunciado aproximadamente como “Réin-dahl”), 
com base nos sobrenomes de seus inventores, Daemen e Rijmen. O AES admite tamanhos de chave 
de 128, 192 ou 256 bits, e o tamanho de bloco é de 128 bits. O AES permite implementações rápidas 
em software e em hardware. Ele não exige muita memória, o que o torna adequado para pequenos 
dispositivos móveis. O AES tem algumas propriedades de segurança comprovadas matematicamente 
e, no momento em que este livro foi escrito, não tinha sofrido quaisquer ataques significativos bem 
sucedidos.‘ 


?Usamos o termo participante para indicar as partes envolvidas em uma comunicação segura, pois esse é o termo que 
estivemos usando no decorrer do livro para identificar as duas extremidades de um canal. No mundo da segurança, eles 
tipicamente são chamados de principais. 

30 motivo para a cifração 3DES usar a decifração DES com DES-chave2Z é para prover interoperabilidade com os sistemas 
DES legados. Se um sistema DES legado utilizar uma única chave, então um sistema 3DES pode realizar a mesma função 
de cifração usando essa chave no lugar de DES-chavel, DES-chave2 e DES-chave3; nas duas primeiras etapas, ciframos 
e depois deciframos com a mesma chave, produzindo o texto às claras original, que então ciframos novamente. 

“Como qualquer coisa capaz de recuperar o texto às claras com menos esforço computacional do que a mera força bruta 
é tecnicamente classificado como um ataque, existem algumas formas de ataque ao AES que foram publicadas. Embora elas 
se saiam um pouco melhor do que a força bruta, elas continuam sendo computacionalmente muito dispendiosas. 
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8.1.3 Cifras de chave pública 


Uma alternativa às cifras de chave simétrica são as cifras assimétricas, ou de chave pública. Ao invés 
de uma única chave compartilhada por dois participantes, uma cifra de chave pública usa um par de 
chaves relacionadas, uma para a cifração e uma diferente para a decifração. O par de chaves “pertence” 
a apenas um participante. O proprietário mantém a chave de decifração secreta, de modo que somente 
ele possa decifrar as mensagens; essa chave é chamada de chave privada. O proprietário torna a chave 
de cifração pública, de modo que qualquer um possa cifrar mensagens destinadas ao seu proprietário; 
essa chave é chamada de chave pública. Obviamente, para que esse esquema funcione, não deverá ser 
possível deduzir a chave privada a partir da chave pública. Consequentemente, qualquer participante 
pode receber a chave pública e enviar uma mensagem cifrada para o proprietário das chaves, e somente 
o proprietário tem a chave privada necessária para decifrar a mensagem. Esse cenário é representado 
na Figura 8.3. 

Por ser um tanto contraintuitivo, enfatizamos que a chave de cifração pública é inútil para decifrar 
uma mensagem — você nem sequer poderia decifrar uma mensagem que você mesmo acabou de ci- 
frar, a menos que tivesse a chave de decifração privada. Se pensarmos nas chaves como definindo um 
canal de comunicação entre os participantes, então outra diferença entre as cifras de chave pública e 
de chave simétrica é a topologia dos canais. Uma chave para uma cifra de chave simétrica oferece um 
canal que é bidirecional entre dois participantes — cada participante mantém a mesma chave (simé- 
trica) que qualquer um pode usar para cifrar ou decifrar mensagens em qualquer direção. Um par de 
chaves pública/privada, por outro lado, oferece um canal que é unidirecional e de muitos para um, de 
qualquer um que tenha a chave pública para o proprietário (único) da chave privada, conforme ilus- 
trado na Figura 8.3. 

Uma propriedade adicional importante das cifras de chave pública é que a chave de “decifração” 
privada pode ser usada com o algoritmo de cifração para cifrar mensagens de modo que elas só possam 
ser decifradas usando a chave de “cifração” pública. Essa propriedade claramente não seria útil para 
confidencialidade, pois qualquer um com a chave pública poderia decifrar tal mensagem. (Na verdade, 
para a confidencialidade bidirecional entre dois participantes, cada participante precisa do seu próprio 
par de chaves, e cada um cifra mensagens usando a chave pública do outro.) Essa propriedade, porém, 
é útil para autenticação, pois ela diz ao receptor dessa mensagem que ela só poderia ter sido criada pelo 
proprietário das chaves (sujeito a certas suposições, conforme veremos mais adiante). Isso é ilustrado na 
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FIGURA 8.3 Criptografia de chave pública. 
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FIGURA 8.4 Autenticação usando chaves públicas. 


Figura 8.4. Deve ficar claro pela figura que qualquer um com a chave pública pode decifrar a mensagem 
cifrada e, supondo que o resultado da decifração corresponde ao resultado esperado, pode-se concluir 
que a chave privada precisa ter sido usada para realizar a cifração. Exatamente como essa operação é 
usada para fornecer autenticação é o assunto da Seção 8.3. Conforme veremos, as cifras de chave pública 
são usadas principalmente para autenticação e para distribuir chaves simétricas confidencialmente, 
deixando o restante da confidencialidade para as cifras de chave simétrica. 

Vejamos alguns fatos históricos interessantes. O conceito de cifras de chave pública foi publicado 
inicialmente em 1976 por Diffie e Hellman. Mais tarde, porém, apareceram documentos provando que 
o Communications-Electronics Security Group da Grã-Bretanha tinha descoberto as cifras de chave pú- 
blica em 1970, e a Agência de Segurança Nacional (NSA — National Security Agency) dos Estados Unidos 
afirma tê-las descoberto em meados da década de 1960. 

A cifra de chave pública mais conhecida é o RSA, que foi nomeada em função dos sobrenomes de 
seus inventores: Rivest, Shamir e Adleman. A segurança do RSA depende do alto custo computacional da 
fatoração de números grandes. Encontrar um modo eficiente de fatorar números é um problema sobre 
o qual os matemáticos têm trabalhado sem sucesso desde muito tempo antes que o RSA aparecesse 
em 1978, e a resistência subsequente do RSA à criptanálise reforçou ainda mais a confiança em sua 
segurança. Infelizmente, o RSA precisa de chaves relativamente grandes, pelo menos com 1024 bits, 
para ser seguro. Isso é maior do que as chaves para as cifras de chave simétrica, pois é mais rápido 
quebrar uma chave privada RSA fatorando o número grande no qual o par de chaves é baseado do que 
pesquisando exaustivamente o espaço de chaves. 

Outra cifra de chave pública é o ElGamal. Assim como o RSA, sua segurança depende de um problema 
matemático, o problema do logaritmo discreto, para o qual nenhuma solução eficiente foi descoberta, e 
exige chaves de pelo menos 1024 bits. Existe uma variação do problema do logaritmo discreto, que surge 
quando a entrada é uma curva elíptica, que é considerado ainda mais difícil de calcular; os esquemas 
criptográficos baseados nesse problema são conhecidos como criptografia de curvas elípticas.’ 

As cifras de chave pública, infelizmente, são várias ordens de grandeza mais lentas do que as cifras 
de chave simétrica. Por conseguinte, as cifras de chave simétrica são usadas para a grande maioria 
das situações que exigem cifração, enquanto as cifras de chave pública são reservadas para uso na 
autenticação (Seção 8.1.4) e no estabelecimento de chaves de sessão (Seção 8.2). 


8.1.4 Autenticadores 


A cifração apenas não oferece integridade de dados. Por exemplo, simplesmente modificar uma men- 
sagem de texto cifrado aleatoriamente poderia transformá-la em algo que é decifrado em um texto às 
claras aparentemente válido, situação na qual a modificação seria indetectável pelo receptor. A cifração 
sozinha também não oferece autenticação. Não adianta muito dizer que uma mensagem veio de um 


5A criprografia de curvas elípticas utiliza chaves e assinaturas menores do que tradicionalmente obtido com o RSA. Esse 
potencial, aliado à segurança do problema subjacente do logaritmo discreto elíptico, tem levado à sua ampla adoção no 
mundo todo, inclusive no Brasil. (N.T.) 
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certo participante se o conteúdo da mensagem tiver sido modificado depois que esse participante a 
criou. De certa forma, integridade e autenticação são fundamentalmente inseparáveis. 

Um autenticador é um valor, a ser incluído em uma mensagem transmitida, que pode ser usado 
para verificar simultaneamente a autenticidade e a integridade dos dados de uma mensagem. Na Seção 
8.3, veremos como os autenticadores podem ser usados nos protocolos. Por enquanto, focalizamos os 
algoritmos que produzem autenticadores. 

Você deve se lembrar que, na Seção 2.4.3, vimos as somas de verificação e as verificações de redun- 
dância cíclica (CRCs) — informações adicionais enviadas com a mensagem original - como maneiras 
de detectar quando uma mensagem foi modificada inadvertidamente por erros de bit. Um conceito 
semelhante se aplica aos autenticadores, com o desafio adicional de que a adulteração da mensagem 
provavelmente será deliberadamente realizada por alguém que queira que a modificação não seja 
detectada. Para permitir a autenticação, um autenticador inclui alguma prova de que quem criou o 
autenticador conhece um segredo que é conhecido apenas pelo emissor alegado da mensagem; por 
exemplo, o segredo poderia ser uma chave, e a prova poderia ser algum valor cifrado usando a chave. 
Existe uma dependência mútua entre a forma da informação redundante e a forma da prova do co- 
nhecimento secreto. Discutimos várias combinações funcionais. 

Inicialmente, vamos supor que a mensagem original não precise ser confidencial - que uma mensa- 
gem transmitida consistirá no texto às claras da mensagem original mais um autenticador. Mais adiante, 
vamos considerar o caso onde a confidencialidade é desejada. 

Um tipo de autenticador combina a cifração e uma função de hash criptográfico. Os algoritmos 
de hash criptográfico são tratados como sendo de conhecimento público, assim como os algoritmos 
de cifra. Uma função de hash criptográfico (também conhecida como soma de verificação criptográfica 
ou função de resumo criptográfico) é uma função que gera informações redundantes suficientes sobre 
uma mensagem para expor qualquer mudança maliciosa nela. Assim como uma soma de verificação 
ou CRC expõem erros de bit introduzidos por enlaces com ruído, uma soma de verificação criptográfica 
é preparada para expor mudanças deliberadas das mensagens por um adversário. O valor que ela 
gera é chamado de resumo de mensagem (message digest) e, como uma soma de verificação comum, é 
anexado à mensagem. Todos os resumos de mensagem produzidos por determinada função de hash 
têm o mesmo número de bits, independente do tamanho da mensagem original. Como o espaço de 
mensagens de entrada possíveis é maior do que o espaço dos resumos de mensagem possíveis, haverá 
diferentes mensagens de entrada que produzem o mesmo resumo de mensagem, como colisões em 
uma tabela de hash. 

Um autenticador pode ser criado cifrando o resumo da mensagem. O receptor calcula um resumo 
da parte de texto às claras da mensagem e o compara com o resumo da mensagem decifrada. Se eles 
forem iguais, então o receptor concluiria que a mensagem é realmente do seu emissor alegado (pois 
ela teria que ter sido cifrada com a chave correta) e não foi modificada. Nenhum adversário poderia 
passar desapercebido ao enviar uma mensagem falsa com um resumo falso correspondente, pois ele não 
teria a chave para cifrar o resumo falso corretamente. Porém, um adversário poderia obter a mensagem 
original em texto às claras e seu resumo cifrado por meio de uma escuta. O adversário poderia, então 
(como a função de hash é de conhecimento público), calcular o resumo da mensagem original e gerar 
mensagens alternativas em busca de uma que tenha o mesmo resumo de mensagem. Se encontrar 
uma, ele poderia enviar, sem ser detectado, a nova mensagem com o autenticador antigo. Portanto, por 
questões de segurança exige-se que a função de hash tenha a propriedade de ser unidirecional: deverá 
ser computacionalmente inviável para um adversário encontrar qualquer mensagem de texto às claras 
que tenha o mesmo resumo da original. 

Para uma função de hash satisfazer esse requisito, suas saídas devem ser distribuídas de forma bas- 
tante aleatória. Por exemplo, se os resumos tiverem 128 bits e forem distribuídos aleatoriamente, então 
você precisaria testar 2!2” mensagens, em média, antes de encontrar uma segunda mensagem cujo 
resumo corresponda ao de uma mensagem dada. Se as saídas não forem distribuídas aleatoriamente — 
ou seja, se algumas saídas forem muito mais prováveis do que outras —, então, para algumas mensagens, 
você poderia encontrar outra mensagem com o mesmo resumo muito mais facilmente do que isso, o que 
reduziria a segurança do algoritmo. Se você, em vez disso, estivesse simplesmente tentando encontrar 
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qualquer colisão — duas mensagens quaisquer que produzam um mesmo resumo -, então precisaria 
calcular os resumos de apenas 2º! mensagens, em média. Esse fato surpreendente é a base do “ataque 
do aniversário” — veja mais detalhes nos exercícios. 

Existem vários algoritmos de hash criptográfico comuns, incluindo o Message Digest 5 (MD5) e o 
Secure Hash Algorithm 1 (SHA-1). O MDS gera um resumo de 128 bits, e o SHA-1 gera um resumo de 
160 bits. As deficiências do MDS já são conhecidas há algum tempo, o que levou a recomendações para 
passar do MD5 para o SHA-1. Mais recentemente, pesquisadores descobriram técnicas que encontram 
colisões no SHA-1 de forma muito mais eficiente do que a força bruta, mas elas ainda não são computa- 
cionalmente viáveis. Embora os ataques de colisão (ataques baseados na descoberta de qualquer colisão) 
não sejam um risco tão grande quanto os ataques de pré-imagem (ataques baseados em encontrar uma 
segunda mensagem que colide com uma primeira mensagem dada), estas são deficiências sérias. O 
NIST recomendou a substituição do SHA-1 a partir de 2010, em favor de quatro variantes do SHA que 
são coletivamente conhecidas como SHA-2. Existe uma competição em andamento’ para criar um novo 
hash, conhecido como SHA-3. 

Ao gerar um resumo criptográfico cifrado, a cifração do resumo poderia usar ou uma cifra de chave 
simétrica ou uma cifra de chave pública. Se uma cifra de chave pública for usada, o resumo seria ci- 
frado usando a chave privada do emissor (aquela que normalmente pensamos como sendo usada para 
a decifração), e o receptor — ou qualquer outra entidade — poderia decifrar o resumo usando a chave 
pública do emissor. 

Um resumo cifrado com um algoritmo de chave pública, porém usando a chave privada, é chamado 
de assinatura digital, pois oferece irretratabilidade, como uma assinatura manual. O receptor de uma 
mensagem com uma assinatura digital pode provar a qualquer terceiro que o emissor realmente enviou 
essa mensagem, pois o terceiro pode usar a chave pública do emissor para verificar por si mesmo. (A 
cifração de chave simétrica de um resumo não tem essa propriedade, pois somente os dois participantes 
conhecem a chave; além disso, como os dois participantes conhecem a chave, o suposto receptor poderia 
ter criado a mensagem ele mesmo.) Qualquer cifra de chave pública pode ser usada para assinaturas 
digitais. O Digital Signature Standard (DSS) é um formato de assinatura digital que foi padronizado pelo 
NIST. As assinaturas DSS podem usar qualquer uma dentre três cifras de chave pública, uma baseada em 
RSA, outra no ElGamal e uma terceira chamada Elliptic Curve Digital Signature Algorithm (EC-DSA). 

Um outro tipo de autenticador é semelhante, porém, em vez de cifrar um hash, ele usa uma função 
semelhante à função de hash que usa um valor secreto (conhecido apenas pelo emissor e pelo receptor) 
como parâmetro, conforme ilustrado na Figura 8.5. Essa função gera um autenticador chamado Código 
de Autenticação de Mensagem (MAC — Message Authentication Code). O emissor anexa o MAC à sua 
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FIGURA 8.5 Calculando um MAC (a) e calculando um HMAC (b). 


60 final do concurso do SHA-3 é previsto para acontecer no final de 2012. No momento da tradução deste livro, o concurso 
estava em sua terceira fase, contando com três finalistas: Keccak, Skein, BLAKE, Grostl, e JH. (N.T.) 
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mensagem em texto às claras. O receptor recalcula o MAC usando o texto às claras e o valor secreto, e 
compara esse MAC recalculado com o MAC recebido. 

Uma variação comum dos MACs é aplicar um hash criptográfico (como MDS ou SHA-1) à conca- 
tenação da mensagem em texto às claras com o valor secreto, conforme ilustra a Figura 8.5. O resumo 
resultante é chamado código de autenticação de mensagem baseado em hash (HMAC - Hashed Message 
Authentication Code), pois é basicamente um MAC. O HMAC, mas não o valor secreto, é anexado à 
mensagem de texto às claras. Somente um receptor que conhece o valor secreto pode calcular o HMAC 
correto para comparar com o HMAC recebido. Se não fosse pela propriedade unidirecional do hash, um 
adversário poderia ser capaz de descobrir a entrada que gerou o HMAC e compará-la com a mensagem 
de texto às claras para determinar o valor secreto. 

Até este ponto, estivemos considerando que a mensagem não era confidencial, de modo que a mensa- 
gem original poderia ser transmitida como texto às claras. Para acrescentar confidencialidade à mensagem 
com um autenticador, basta cifrar a concatenação da mensagem inteira, incluindo seu autenticador — o 
MAC, HMAC ou resumo cifrado. Lembre-se que, na prática, a confidencialidade é implementada usando 
cifras de chave simétrica, pois elas são muito mais rápidas do que as cifras de chave pública. Além disso, 
custa pouco incluir um autenticador na cifração, e isso aumenta a segurança. Uma simplificação comum 
é cifrar a mensagem com seu resumo (bruto), de modo que o resumo seja apenas cifrado uma vez; nesse 
caso, a mensagem de texto cifrado inteira é considerada como um autenticador.” 


8.2 Pré-distribuição de chaves 


Para usar cifras e autenticadores, os participantes da comunicação precisam saber quais chaves usar. No 
caso das cifras de chave simétrica, como um par de participantes obtém a chave que eles compartilham? 
No caso de uma cifra de chave pública, como os participantes sabem que chave pública pertence a um 
participante? A resposta varia, dependendo de se as chaves são chaves de sessão, de curta duração, ou 
chaves pré-distribuídas, com mais longa duração. 

Uma chave de sessão é uma chave usada para proteger um único episódio de comunicação relativa- 
mente curto: uma sessão. Cada sessão distinta entre um par de participantes utiliza uma nova chave de 
sessão, que é sempre uma chave simétrica para se obter maior velocidade. Os participantes determinam 
qual chave de sessão usar por meio de um protocolo — um protocolo de estabelecimento de chave de 
sessão. Um protocolo de estabelecimento de chave de sessão requer sua própria segurança (de modo 
que, por exemplo, um adversário não possa descobrir a nova chave de sessão); essa segurança é baseada 
nas chaves pré-distribuídas de mais longa duração. 

Existem várias motivações para essa divisão de trabalho entre as chaves de sessão e as chaves 
pré-distribuídas: 


e Limitar a quantidade de tempo em que uma chave é usada resulta em menos tempo para ataques 
computacionalmente intensos, menos texto cifrado para ser usado na criptanálise e menos 
informações expostas caso a chave seja descoberta. 

e Apré-distribuição de chaves simétricas é problemática. 

e Ascifras de chave pública geralmente são melhores para as tarefas de autenticação e 
estabelecimento de chaves de sessão, mas muito lentas para uso na cifração de mensagens 
inteiras para se obter confidencialidade. 


Esta seção explica como as chaves pré-distribuídas são distribuídas, e a Seção 8.3 explicará como 
as chaves de sessão são então estabelecidas. Daqui por diante, usaremos “Alice” e “Bob” para designar 
os participantes, como é comum na literatura sobre criptografia. Lembre-se que, embora seja comum 
nos referirmos aos participantes em termos antropomórficos, geralmente nos preocupamos mais com a 
comunicação entre as entidades de software e hardware, como clientes e servidores, que frequentemente 
não possuem relacionamento direto com qualquer pessoa em particular. 


7É importante notar que existem estratégias padronizadas, bem como boas práticas, para fornecer confidencialidade 
e autenticação às mensagens. Estratégias levianas, apesar de aparentemente seguras, podem esconder falhas catastróficas. Embora 
possa parecer que os autenticadores resolvem o problema da autenticação, veremos na Seção 8.3 que eles são apenas o alicerce 
de uma solução. Primeiro, porém, trataremos da questão de como os participantes obtêm chaves em primeiro lugar. (N.T) 
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8.2.1 Pré-distribuição de chaves públicas 


Os algoritmos para gerar um par correspondente de chaves pública e privada são publicamente co- 
nhecidos, e o software que faz isso está disponível com facilidade. Assim, se Alice quisesse usar uma cifra 
de chave pública, ela poderia gerar seu próprio par de chaves pública e privada, manter a chave privada 
oculta e publicar a chave pública. Porém, como ela pode publicar sua chave pública — afirmando que a 
chave pertence a ela - de modo que outros participantes possam estar certos de que a chave realmente 
pertence a Alice? Não via e-mail ou Web, pois um adversário poderia forjar uma afirmação igualmente 
plausível de que a chave x pertence à Alice quando x na realidade pertence ao adversário. 

Um esquema completo para certificar vínculos entre chaves públicas e identidades - que chave per- 
tence a quem - é chamado de Infraestrutura de Chaves Públicas (PKI— Public Key Infrastructure) º Uma 
PKI começa com a capacidade de verificar identidades e vinculá-las a chaves fora da banda. Com “fora 
da banda”, queremos dizer algo fora da rede e dos computadores que a compõem, como nos cenários a 
seguir. Se Alice e Bob são indivíduos que conhecem um ao outro, então eles poderiam se reunir na mesma 
sala e Alice poderia dar sua chave pública a Bob diretamente, talvez em um cartão de visita. Se Bob 
é uma organização, o indivíduo Alice poderia apresentar identificação convencional, talvez envolvendo 
uma fotografia ou impressões digitais. Se Alice e Bob são computadores pertencentes à mesma empresa, 
então um administrador de sistemas poderia configurar Bob com a chave pública de Alice. 

O estabelecimento de chaves fora da banda parece não ser muito escalável, mas é suficiente para 
dar início a uma PKI. O conhecimento de Bob de que a chave de Alice é x pode ser disseminado de 
forma ampla e escalável usando uma combinação de assinaturas digitais e um conceito de confiança. 
Por exemplo, suponha que você tenha recebido a chave pública de Bob fora da banda e que saiba o 
suficiente sobre Bob para confiar nele em questões de chaves e identidades. Então Bob poderia lhe 
enviar uma mensagem declarando que a chave de Alice é x e - como você já conhece a chave pública 
de Bob -, poderia autenticar a mensagem como sendo vinda de Bob. (Lembre-se que, para assinar 
a declaração digitalmente, Bob anexaria um hash criptográfico dela que tenha sido cifrado usando 
sua chave privada.) Como você confia que Bob diz a verdade, agora você saberia que a chave de 
Alice é x, embora você nunca tivesse se encontrado com ela ou trocado uma única mensagem com 
ela. Usando assinaturas digitais, Bob nem sequer teria que lhe enviar uma mensagem; ele poderia 
simplesmente criar e publicar uma declaração assinada digitalmente de que a chave de Alice é x. 
Essa declaração assinada digitalmente do vínculo de uma chave pública à identidade de seu dono é 
chamada certificado de chave pública, ou simplesmente certificado. Bob poderia enviar a Alice uma 
cópia do certificado, ou postá-lo em um site Web. Se e quando alguém precisar verificar a chave 
pública de Alice, poderia fazer isso obtendo uma cópia do certificado, talvez diretamente de Alice — 
desde que este alguém confie em Bob e conheça sua chave pública. Você pode ver como, começando 
de um número muito pequeno de chaves (neste caso, apenas a de Bob), você poderia montar um 
grande conjunto de chaves confiáveis com o tempo. Bob, neste caso, está desempenhando o papel 
normalmente chamado de Autoridade Certificadora (CA — Certification Authority), e grande parte 
da segurança da Internet de hoje depende de CAs. A VeriSign? é uma CA comercial bem conhecida. 
Voltaremos a esse assunto mais adiante. 

Um dos principais padrões para certificados é conhecido como X.509. Esse padrão deixa muitos 
detalhes em aberto, mas especifica uma estrutura básica para os certificados. Os componentes de um 
certificado claramente precisam incluir: 


e Aidentidade da entidade sendo certificada. 

e A chave pública da entidade sendo certificada. 

e Aidentidade da autoridade que assina o certificado. 

e Aassinatura digital. 

e Oidentificador de um algoritmo da assinatura digital (qual hash criptográfico e qual cifra). 


“Na literatura especializada, o termo Infraestrutura de Chaves Públicas, ou PKI, é comumente reservado para arranjos 
baseadas em certificados assinados por autoridades certificadoras, conforme o descrito no texto. Entretanto, neste livro 
o termo é usado de forma mais ampla, indicando qualquer esquema que permite o estabelecimento de um relacionamento 
confiável entre uma chave pública e a identidade de seu dono. (N.T.) 
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Outro componente possível é uma data de expiração para o certificado. Veremos um uso particular 
desse recurso mais adiante. 

Como um certificado cria um vínculo entre uma identidade e uma chave pública, deveríamos exa- 
minar mais de perto o que significa “identidade”. Por exemplo, um certificado que diz que “esta chave 
pública pertence a João da Silva” pode não ser muito útil se você não souber qual dos milhares de João 
da Silva está sendo identificado. Assim, os certificados precisam usar um espaço de nomes bem definido 
para as identidades sendo certificadas; por exemplo, os certificados normalmente são emitidos para 
endereços de e-mail e domínios de DNS. 

Existem diferentes maneiras como uma PKI poderia formalizar a noção de confiança. Discutimos 
os dois métodos principais. 


Autoridades certificadoras 

Neste modelo de confiança, a confiança é binária; ou você confia em alguém completamente ou não 
confia de forma alguma. Junto com os certificados, isso permite a construção de cadeias de confiança. 
Se X certifica que uma chave pública pertence a Y, e depois Y, por sua vez, certifica que outra chave 
pública pertence a Z, então existe uma cadeia de certificados de X para Z, embora X e Z possam nunca 
ter se encontrado. Se você conhece a chave de X— e você confia em X e Y-, então pode acreditar no 
certificado que fornece a chave de Z. Em outras palavras, tudo o que você precisa é de uma cadeia de 
certificados, todos assinados por entidades em que você confia, desde que isso leve de volta a uma 
entidade cuja chave pública você já conhece. 

Uma autoridade certificadora (CA — Certification Authority) ou autoridade de certificado é uma 
entidade considerada (por alguém) como sendo confiável para verificar identidades e emitir certificados 
de chave pública. Existem CAs comerciais, CAs governamentais e até mesmo CAs independentes. Para 
usar uma CA, você precisa conhecer a chave dela. Porém, você pode descobrir a chave dessa CA se for 
capaz de obter uma cadeia de certificados assinados por CAs que comece com uma CA cuja chave você 
já conhece. Depois, você poderá acreditar em qualquer certificado assinado por essa nova CA. 

Uma forma comum de criar tais cadeias é organizá-las em uma hierarquia estruturada em árvore, 
como mostrado na Figura 8.6. Se todos tiverem a chave pública da CA raiz, então qualquer participante 
pode fornecer uma cadeia de certificados para outro participante e saber que isso será suficiente para 
construir uma cadeia de confiança para aquele participante. 

Existem algumas questões significativas com a criação de cadeias de confiança. A mais importante é 
que, mesmo que você esteja certo de que tem a chave pública da CA raiz, você precisa ter certeza de que 
toda CA abaixo da raiz está realizando seu trabalho corretamente. Se apenas uma CA na cadeia estiver 
disposta a emitir certificados para entidades sem verificar suas entidades, então o que parece ser uma 
cadeia de certificados válida perde o significado. Por exemplo, uma CA raiz poderia emitir um certificado 
para uma CA de segundo nível e verificar cuidadosamente que o nome do certificado corresponde ao 
nome da empresa da CA, mas essa CA de segundo nível poderia estar disposta a vender certificados 
para qualquer um que solicite, sem verificar sua identidade. Esse problema piora quanto maior for a 
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FIGURA 8.6 Hierarquia de autoridades certificadoras estruturada em árvore. 
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cadeia de confiança. Os certificados X.509 oferecem a opção de restringir o conjunto de entidades que 
o sujeito de um certificado, por sua vez, pode certificar. 

Pode haver mais de uma raiz em uma árvore de certificação, e isso é comum na proteção de tran- 
sações pela Web hoje em dia, por exemplo. Navegadores Web como Firefox e Internet Explorer vêm 
previamente equipados com certificados para um conjunto de CAs; com efeito, o produtor do navegador 
decidiu que se pode confiar nessas CAs e em suas chaves. Um usuário também pode acrescentar CAs 
àquelas que seu navegador reconhece como confiáveis. Esses certificados são aceitos pelo Secure Socket 
Layer (SSL) /Transport Layer Security (TLS), o protocolo mais utilizado para proteger transações na 
Web, que discutimos mais adiante, na Seção 8.4.3. (Se você estiver curioso, poderá dar uma olhada nas 
configurações de preferências do seu navegador e encontrar a opção que “lista os certificados”, para 
ver em quantas CAs seu navegador está configurado para confiar.) 


Rede de confiança (Web of Trust) 

Um modelo de confiança alternativo é a Rede de confiança (Web of Trust), exemplificado pelo Pretty Good 
Privacy (PGP), que é discutido com mais detalhes na Seção 8.4.3. O PGP é um sistema de segurança para 
e-mail, de modo que os endereços de e-mail são as identidades às quais as chaves são vinculadas e para 
os quais os certificados são assinados. Dado que o PGP em suas origens tinha como objetivo a proteção 
contra intrusões do governo, não existem CAs. Em vez disso, os indivíduos decidem individualmente em 
quem eles confiam e o quanto eles confiam — nesse modelo, a confiança é uma questão de grau. Além 
disso, um certificado de chave pública pode incluir um nível de confiança indicando a confiança que 
um assinante tem no vínculo chave-identidade declarado no certificado, de modo que determinado 
usuário pode precisar ter vários certificados atestando o mesmo vínculo de chave-identidade antes que 
esteja disposto a confiar nele. 

Por exemplo, suponha que você tenha um certificado para Bob, fornecido por Alice; você pode atribuir 
um nível de confiança moderado para esse certificado. Porém, se você tiver certificados adicionais para 
Bob, que foram fornecidos por Ce D, cada um deles também moderadamente confiável, isso poderia 
aumentar consideravelmente seu nível de confiança de que a chave pública que você tem para Bob é 
válida. Resumindo, o PGP reconhece que o problema de estabelecimento de confiança é uma questão 
muito pessoal e dá aos usuários a matéria-prima para tomar suas próprias decisões, em vez de supor 
que todos eles querem confiar em uma única estrutura hierárquica de CAs. Citando Phil Zimmerman, 
o desenvolvedor do PGP: “O PGP é para pessoas que preferem embalar seu próprio pára-quedas”. 

O PGP tornou-se muito popular na comunidade de redes, e encontros para assinaturas de chaves 
PGP são eventos comuns nas reuniões da IETF Nesses encontros, um indivíduo pode: 


e Coletar chaves públicas de outros, cuja identidade ele conheça. 

e Fornecer sua chave pública a outros. 

e Obter a assinatura de sua chave pública por outros, reunindo assim certificados que serão 
persuasivos a um grupo incrivelmente grande de pessoas. 

e Assinar a chave pública de outros indivíduos, ajudando-os, assim, a acumular seu conjunto de 
certificados que eles podem usar para distribuir suas chaves públicas. 

e Coletar certificados de outros indivíduos em quem ele confia o suficiente para assinar chaves. 


Assim, com o tempo, um usuário reunirá um conjunto de certificados com graus de confiança 
variados. 


Revogação de certificados 

Uma questão que surge com os certificados é como revogar ou desfazer um certificado. Por que isso é 
importante? Suponha que você suspeite que alguém descobriu sua chave privada. Pode haver qualquer 
quantidade de certificados no universo que garanta que você é o proprietário da chave pública corres- 
pondente a essa chave privada. A pessoa que descobriu sua chave privada, portanto, tem tudo o que 
precisa para personificá-lo: certificados válidos e sua chave privada. Para resolver esse problema, seria 
bom poder revogar os certificados que vinculam sua antiga chave comprometida à sua identidade, de 
modo que um impostor não seja capaz de persuadir outras pessoas a pensarem que ele é você. 
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A solução básica para o problema é muito simples. Cada autoridade certificadora pode emitir uma 
lista de revogação de certificados (CRL — Certificate Revocation List), que é uma lista assinada digital- 
mente, contendo certificados que foram revogados. A CRL é atualizada periodicamente e encontra-se 
publicamente disponível. Por ser assinada digitalmente, ela pode simplesmente ser postada em um site 
Web. Então, quando Alice recebe um certificado para Bob e quer verificá-lo, ela primeiro consulta a CRL 
mais recente emitida pela CA. Se o certificado não tiver sido revogado, ele será válido. Observe que, se 
todos os certificados tivessem validade ilimitada, a CRL sempre ficaria cada vez maior, pois você nunca 
poderia retirar um certificado da CRL, com medo de que alguma cópia do certificado revogado pudesse 
ser usada. Por esse motivo, é comum acrescentar uma data de expiração a um certificado quando ele 
é emitido. Assim, podemos limitar o tempo que um certificado revogado precisa permanecer em uma 
CRL. Assim que sua data de expiração original tiver vencido, ele poderá ser removido da CRL. 


8.2.2 Pré-distribuição de chaves simétricas 


Se Alice quiser usar uma cifra de chave secreta para se comunicar com Bob, ela não pode simplesmente 
escolher uma chave e enviá-la para ele porque, sem já ter uma chave, eles não podem cifrar essa chave 
para mantê-la confidencial, e não podem autenticar um ao outro. Assim como nas chaves públicas, é 
necessário que haja algum esquema de pré-distribuição. A pré-distribuição é mais difícil para chaves 
simétricas do que para chaves públicas por dois motivos óbvios: 


e Embora somente uma chave pública por entidade seja suficiente para autenticação e 
confidencialidade, é preciso haver uma chave simétrica para cada par de entidades que queiram 
se comunicar. Se houver N entidades, isso significa N(N — 1)/2 chaves. 

e Diferente das chaves públicas, as chaves secretas precisam ser mantidas em segredo. 


Em suma, existem muitos mais chaves para distribuir, e você não pode usar certificados que todos 
possam ler. 

A solução mais comum é usar um Centro de Distribuição de Chaves (KDC — Key Distribution Center). 
Um KDC é uma entidade de confiança que compartilha uma chave secreta com cada uma das outras 
entidades. Isso reduz o número de chaves para N- 1, o suficiente para ser estabelecido fora da banda 
para algumas aplicações. Quando Alice deseja se comunicar com Bob, essa comunicação não trafega 
pelo KDC. Em vez disso, o KDC participa de um protocolo que autentica Alice e Bob — usando as chaves 
que o KDC já compartilha com cada um deles — e gera uma nova chave de sessão para que eles utilizem. 
Depois, Alice e Bob se comunicam diretamente usando sua chave de sessão. O Kerberos (Seção 8.3.3) 
é um sistema baseado nessa técnica que é bastante usado. 


8.3 Protocolos de autenticação 


Descrevemos como cifrar mensagens e montar autenticadores na Seção 8.1 e como pré-distribuir as cha- 
ves necessárias na Seção 8.2. Pode parecer que tudo o que temos a fazer para tornar um protocolo seguro 
é anexar um autenticador a cada mensagem e, se quisermos confidencialidade, cifrar a mensagem. 

Existem duas razões principais pelas quais isso não é tão simples. Primeiro, existe o problema de 
um ataque de repetição: um adversário retransmitindo uma cópia de uma mensagem que foi enviada 
anteriormente. Se a mensagem foi um pedido que você fez em um site, por exemplo, então a mensagem 
repetida apareceria para o site como se você tivesse feito um pedido igual novamente. Embora esta 
não seja instância original da mensagem, seu autenticador ainda seria válido; afinal, a mensagem foi 
criada por você, e ela não foi modificada. Em uma variação desse ataque, chamada ataque de repetição 
com supressão, um adversário poderia simplesmente atrasar sua mensagem (interceptando-a e depois 
reproduzindo-a), de modo que ela seja recebida em um instante que não seja mais apropriado. Por 
exemplo, um adversário poderia adiar seu pedido para comprar ações da bolsa em um momento 
favorável para um momento em que você não desejaria comprar. Embora essa mensagem, de certa 
forma, seja a original, ela não estaria chegando em tempo. Originalidade e pontualidade podem ser 
considerados aspectos da integridade. Na maior parte dos casos, sua garantia exige um protocolo não 
trivial, envolvendo mensagens indo de um lado para outro da comunicação. 
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O outro problema que ainda não resolvemos é como estabelecer uma chave de sessão. Uma chave 
de sessão é uma chave de cifra simétrica gerada no ato e usada para apenas uma sessão, conforme des- 
crito na Seção 8.2. Isso também envolve um protocolo não trivial. 

O que esses dois problemas têm em comum é a autenticação. Se uma mensagem não for original e 
pontual, então, de um ponto de vista prático, queremos considerá-la como não sendo autêntica, não 
sendo de quem ela afirma ser. Obviamente, quando você está se preparando para compartilhar uma nova 
chave de sessão com alguém, deseja saber que a está compartilhando com a pessoa certa. Normalmente, 
protocolos de autenticação estabelecem uma chave de sessão ao mesmo tempo, de modo que, ao final 
do protocolo, Alice e Bob tenham autenticado um ao outro e tenham uma nova chave simétrica para 
usar. Sem uma nova chave de sessão, o protocolo simplesmente autenticaria Alice e Bob em um ponto 
no tempo; uma chave de sessão permite que eles autentiquem as mensagens subsequentes de modo 
eficaz. Em geral, os protocolos de estabelecimento de chave de sessão realizam autenticação (uma ex- 
ceção importante é o Diffie-Hellman; ver Seção 8.3.4), de modo que os termos protocolo de autenticação 
e protocolo de estabelecimento de chave de sessão são quase sinônimos.” 

Existe um conjunto de técnicas básico, usado para garantir originalidade e pontualidade nos pro- 
tocolos de autenticação. Vamos descrever essas técnicas antes de prosseguirmos com a descrição de 
protocolos específicos. 


8.3.1 Técnicas de originalidade e pontualidade 


Vimos que os autenticadores sozinhos não nos permitem detectar mensagens que não são originais 
ou pontuais. Uma técnica usada é incluir um carimbo de tempo na mensagem. Obviamente, o próprio 
carimbo de tempo precisa ser à prova de modificação, de modo que ele precisa ser coberto pelo auten- 
ticador. A principal desvantagem dos carimbos de tempo é que eles exigem sincronismo distribuído de 
relógios. Como nosso sistema dependeria do sincronismo, o próprio sincronismo de relógio precisaria 
ser protegido contra ameaças à segurança, além dos desafios normais de sincronismo de relógio. Ou- 
tro problema é que os relógios distribuídos são sincronizados somente até certo ponto — há uma certa 
margem de erro. Assim, a integridade temporal fornecida pelos carimbos de tempo só é tão boa quanto 
o grau de sincronismo. 

Outra técnica é incluir um nonce — um número aleatório usado apenas uma vez — na mensagem. Os 
participantes podem então detectar ataques de repetição verificando se um nonce foi usado anterior- 
mente. Infelizmente, isso exige que se mantenha o registro de nonces passados, o que poderia levar a 
um grande acúmulo dos mesmos. Uma solução é combinar o uso de carimbos de tempo e nonces, de 
modo que os nonces precisam ser exclusivos somente dentro de um período de tempo. Isso facilita a 
garantia da exclusividade dos nonces enquanto exige apenas um leve sincronismo dos relógios. 

Outra solução para as deficiências dos carimbos de tempo e nonces é usar um ou ambos em um 
protocolo de desafio-resposta. Suponha que usemos um carimbo de tempo. Em um protocolo de 
desafio-resposta, Alice envia um carimbo de tempo para Bob, desafiando Bob a cifrá-lo em uma 
mensagem de resposta (se eles compartilharem uma chave simétrica) ou assiná-lo digitalmente em 
uma mensagem de resposta (se Bob tem uma chave pública, como na Figura 8.7). O carimbo de tempo 
cifrado é como um autenticador que também comprova a pontualidade. Alice pode facilmente verificar 
a pontualidade do carimbo de tempo em uma resposta de Bob, pois esse carimbo de tempo vem do 
próprio relógio de Alice - nenhum sincronismo de relógio distribuído é necessário. Suponha que, em 
vez disso, o protocolo use nonces. Então Alice só precisa registrar os nonces para os quais as respostas 
estão atualmente pendentes e que não estiveram pendentes por muito tempo; qualquer pretensa res- 
posta com um nonce não reconhecido deve ser falsa. 

A beleza do desafio-resposta, que de outra maneira poderia parecer excessivamente complexo, é que 
ele combina pontualidade e autenticação; afinal, somente Bob (e possivelmente Alice, se for usada uma 
cifra de chave simétrica) conhece a chave necessária para cifrar o carimbo de tempo ou nonce nunca visto 
antes. Carimbos de tempo ou nonces são usados na maioria dos protocolos de autenticação a seguir. 


Quando se deseja deixar claro que o protocolo de estabelecimento de chaves de fato envolve autenticação, é comum 
denominá-lo “protocolo de estabelecimento de chaves autenticado”.(N.T.) 
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Alice Bob FIGURA 8.7 Um protocolo de desafio-resposta. 


Ta A=Alice 
B=Bob 
T,=Carimbo de tempo do relógio de Alice 
C = Assinado digitalmente usando 
p B à chave privada de Bob 








8.3.2 Protocolos de autenticação de chave pública 


Na discussão a seguir, consideramos que as chaves públicas de Alice e Bob foram pré-distribuídas a 
ambos por algum meio, como PKI (Seção 8.2.1). Fazemos essa suposição para incluir o caso em que 
Alice acrescenta seu certificado em sua primeira mensagem para Bob, e também o caso em que Bob 
procura um certificado sobre Alice quando ele recebe a primeira mensagem dela. 

O primeiro protocolo (Figura 8.8) depende dos relógios de Alice e Bob estarem sincronizados. 
Alice envia a Bob uma mensagem com um carimbo de tempo e sua identidade no texto às claras 
juntamente com sua assinatura digital. Bob usa a assinatura digital para autenticar a mensagem e o 
carimbo de tempo para verificar se ela é recente. Bob envia de volta uma mensagem com um carimbo 
de tempo e sua identidade em texto às claras, além de uma nova chave de sessão cifrada (para prover 
confidencialidade) usando a chave pública de Alice, tudo assinado digitalmente. Alice pode verificar a 
autenticidade da mensagem e se ela é recente, de modo que ela sabe que pode confiar na nova chave 
de sessão. Para lidar com um sincronismo de relógio imperfeito, os carimbos de tempo poderiam ser 
acrescidos de nonces. 

O segundo protocolo (Figura 8.9) é semelhante mas não depende do sincronismo de relógio. Neste 
protocolo, Alice novamente envia a Bob uma mensagem assinada digitalmente com um carimbo de 
tempo e sua identidade. Como seus relógios não estão sincronizados, Bob não pode ter certeza que 
a mensagem é recente. Bob envia de volta uma mensagem assinada digitalmente com o carimbo 
de tempo original de Alice, seu próprio carimbo de tempo novo e sua identidade. Alice pode verificar 
se a resposta de Bob é recente comparando a hora atual em seu relógio com o carimbo de tempo que 
foi originalmente criado por ela. Então, ela envia a Bob uma mensagem assinada digitalmente com seu 
carimbo de tempo original e uma nova chave de sessão cifrada usando a chave pública de Bob. Bob 
pode verificar se a mensagem é recente porque o carimbo de tempo veio do seu relógio, de modo que 


Alice Bob 





A A=Alice 
B=Bob 
T,=Carimbo de tempo 


LD = Assinado digitalmente 
xX usando a chave privada de X 


x< =Cifrado usando a 
/ © N chave pública de X 





= Nova chave de sessão 








FIGURA 8.8 Um protocolo de autenticação de chave pública que depende de sincronismo. 
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Alice Bob FIGURA 8.9 Um protocolo de autenticação de 
chave pública que não depende de sincronismo. 
Alice verifica seu próprio carimbo de tempo contra 
seu próprio relógio, e Bob faz o mesmo. 
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chave pública de X 





= Nova chave de sessão 








ele sabe que pode confiar na nova chave de sessão. Os carimbos de tempo basicamente servem como 
nonces convenientes, e realmente esse protocolo poderia usar nonces em seu lugar. 


8.3.3 Protocolos de autenticação de chave simétrica 


Conforme explicamos na Seção 8.2.2, somente em sistemas muito pequenos é prático pré-distribuir 
chaves simétricas a cada par de entidades. Focalizamos aqui os sistemas maiores, onde cada entidade 
teria sua própria chave-mestra, somente com um Key Distribution Center (KDC). Nesse caso, os pro- 
tocolos de autenticação baseados em chave simétrica envolvem três partes: Alice, Bob e um KDC. O 
produto final do protocolo de autenticação é uma chave de sessão compartilhada entre Alice e Bob, 
que eles usarão para se comunicar diretamente, sem envolver o KDC. 

O protocolo de autenticação Needham-Schroeder é ilustrado na Figura 8.10. Observe que o KDC 
não autentica realmente a mensagem inicial de Alice e não se comunica com Bob de forma alguma. Em 
vez disso, o KDC usa seu conhecimento das chaves mestra de Alice e Bob para construir uma resposta 
que seria inútil a qualquer um que não seja Alice (pois somente Alice pode decifrá-la) e que contém 
os ingredientes necessários para Alice e Bob realizarem o restante do protocolo de autenticação eles 
próprios. 

O nonce nas duas primeiras mensagens é para garantir a Alice que a resposta do KDC é recente. A 
segunda e terceira mensagens incluem a nova chave de sessão e o identificador de Alice, cifrados juntos 
por meio da chave-mestra de Bob. Isto é uma espécie de versão baseada em chave simétrica de um 
certificado de chave pública; com efeito, trata-se de uma declaração assinada pelo KDC (pois o KDC é 
a única entidade além de Bob que conhece a chave-mestra de Bob) de que a chave de sessão dentro da 
mensagem pertence a Alice e Bob. Embora a intenção do nonce nas duas últimas mensagens seja garantir 
a Bob que a terceira mensagem foi recente, existe uma falha nesse raciocínio — ver Exercício 4. 


Kerberos 
O Kerberos é um sistema de autenticação baseado no protocolo Needham-Schroeder e especializado 
para ambientes cliente/servidor. Originalmente desenvolvido no MIT, ele foi padronizado pela IETF 
e está disponível como produtos de código aberto e comerciais. Vamos analisar aqui algumas das 
inovações interessantes do Kerberos. 

Clientes Kerberos geralmente são usuários humanos, e os usuários se autenticam usando senhas. 
A chave-mestra de Alice, compartilhada com o KDC, é derivada de sua senha — se você conhece a se- 
nha, pode calcular a chave. O Kerberos considera que qualquer um pode acessar fisicamente qualquer 
máquina cliente; portanto, é importante minimizar a exposição da senha de Alice ou da chave-mestra 
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A=Alice 
B=Bob 
N;= Nonce 


PEK =Cifrado usando chave 
Z ~ N| compartilhada por X e Y 


= Nova chave de sessão 








FIGURA 8.10 O protocolo de autenticação Needham-Schroeder. 


não apenas na rede, mas também em qualquer máquina onde ela efetuar um login. O Kerberos tira 
proveito do protocolo Needham-Schroeder para fazer isso. Nesse protocolo, a única vez em que Alice 
precisa usar sua senha é quando ela decifra a resposta do KDC. O software cliente Kerberos espera até 
que a resposta do KDC chegue, pede a Alice para entrar com sua senha, calcula a chave-mestra e decifra 
a resposta do KDC, e depois apaga toda a informação sobre a senha e a chave-mestra para minimizar 
sua exposição. Observe também que o único sinal do Kerberos que um usuário vê é quando ele precisa 
informar uma senha. 

No protocolo Needham-Schroeder, a resposta do KDC a Alice desempenha duas funções: ela lhe dá 
um meio de provar sua identidade (somente Alice pode decifrar a resposta) e lhe dá um tipo de certificado 
de chave simétrica ou “ticket” para apresentar a Bob — a chave de sessão e o identificador de Alice, ci- 
frado com a chave-mestra de Bob. No Kerberos, essas duas funções — e, a propósito, o próprio KDC — são 
separadas (Figura 8.11). Um servidor confiável, chamado servidor de autenticação (AS — Authentication 
Server) desempenha a primeira função do KDC, de oferecer a Alice algo que ela pode usar para provar 
sua identidade — não para Bob desta vez, mas para um segundo servidor confiável, chamado servidor 
de concessão de ticket (TGS — Ticket Granting Server). O TGS desempenha a segunda função do KDC, 
de responder a Alice com um ticket que ela pode apresentar a Bob. O atrativo desse esquema é que, se 
Alice precisar se comunicar com vários servidores, não apenas com Bob, então ela pode obter tickets 
para cada um deles do TGS sem retornar ao AS. 

No domínio da aplicação cliente/servidor que é o alvo do Kerberos, é razoável considerar um grau 
de sincronismo de relógio. Isso permite que o Kerberos use carimbos de tempo e períodos de vida 
ao invés dos nonces do protocolo Needham-Shroeder, eliminando assim as falhas de segurança do 
Needham-Schroeder exploradas no Exercício 4. O Kerberos admite uma gama de algoritmos cripto- 
gráficos que inclui os hashes SHA-1 e MDS, além das cifras de chave simétrica AES, 3DES e DES. 
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FIGURA 8.11 Autenticação Kerberos. 


8.3.4 Acordo de chaves Diffie-Hellman 


O protocolo de acordo de chaves Diffie-Hellman estabelece uma chave de sessão sem usar quaisquer 
chaves pré-distribuídas. As mensagens trocadas entre Alice e Bob podem ser lidas por qualquer um capaz 
de escutar o meio, e mesmo assim o adversário não saberá a chave de sessão que Alice e Bob acabam 
estabelecendo. Por outro lado, o Diffie-Hellman não autentica os participantes. Como raramente é útil 
comunicar-se com segurança sem saber ao certo com quem você está se comunicando, o Diffie-Hellman 
normalmente é estendido de alguma maneira para oferecer autenticação. Um dos principais usos do 
Diffie-Hellman é no protocolo de troca de chaves da Internet (IKE — Internet Key Exchange), uma parte 
central da arquitetura de segurança IP (IPsec — IP Security). 

O protocolo Diffie-Hellman tem dois parâmetros, p e g, ambos sendo públicos e podendo ser usados 
por todos os usuários em determinado sistema. O parâmetro p deve ser um número primo. Os inteiros 
mod p (abreviação de módulo p) vão de 0 a p- 1, pois x mod p é o resto obtido depois que x é dividido 
por p, e formam o que os matemáticos chamam de grupo sob a operação de multiplicação. O parâmetro 
g (normalmente chamado de gerador) deve ser uma raiz primitiva de p: para cada número n de la p-1, 


404 REDES DE COMPUTADORES ELSEVIER 


deve haver algum valor k tal que n=g* mod p. Por exemplo, se p fosse o número primo 5 (um sistema 
real usaria um número muito maior), então poderíamos escolher 2 para ser o gerador g, pois: 


1=2º mod p 
2=2! mod p 
3=2º mod p 
4=2? mod p 


Suponha que Alice e Bob queiram estabelecer uma chave simétrica compartilhada. Alice e Bob, e 
todos os outros, já conhecem os valores de p e g. Alice gera um valor privado aleatório a e Bob gera um 
valor privado aleatório b. Tanto a quanto b são escolhidos do conjunto de números inteiros (1,..., p— 1). 
Alice e Bob derivam seus valores públicos — os valores que eles enviarão um para o outro não cifrados — da 
seguinte forma: o valor público de Alice é 


g” mod p 


e o valor público de Bob é 


g’ mod p 


Em seguida, eles enviam seus valores públicos um ao outro. Finalmente, Alice calcula: 


g” mod p=(g” mod p)º mod p 
e Bob calcula 
g” mod p=(g“mod p} mod p. 


Alice e Bob agora possuem g% mod p (que é igual a g”* mod p) como sua chave simétrica comparti- 
lhada. 

Qualquer adversário conheceria p, g, e os dois valores públicos g” mod p e g mod p. Se o adversário 
fosse capaz de determinar a ou b, ele poderia facilmente calcular a chave resultante. Porém, calcular a 
ou b a partir dessa informação é computacionalmente inviável para valores adequadamente grandes 
de p, a e b; isso é conhecido como o problema do logaritmo discreto. 

Por outro lado, existe o problema da falta de autenticação do protocolo Diffie-Hellman. Um ataque 
que poderia tirar proveito disso é o ataque do homem no meio (man-in-the-middle attack). Suponha que 
Mallory seja uma intrusa com a capacidade de interceptar mensagens. Mallory já conhece p e g, pois 
eles são públicos, e ela gera valores aleatórios privados c e d para usar com Alice e Bob, respectivamente. 
Quando Alice e Bob enviam seus valores públicos um para o outro, Mallory os intercepta e envia seus 
próprios valores públicos, como na Figura 8.12. O resultado é que Alice e Bob acabam compartilhando 
uma chave com Mallory, e não entre eles mesmos. 

Uma variante do Diffie-Hellman, às vezes chamado Diffie-Hellman fixo, dá suporte à autenticação 
de um ou ambos os participantes. Ela depende de certificados que são semelhantes aos certificados de 
chave pública, mas, em vez disso, certificam os parâmetros públicos Diffie-Hellman de uma entidade. Por 
exemplo, tal certificado afirmaria que os parâmetros Diffie-Hellman de Alice são p, ge g' mod p (observe 


Alice Mallory Bob 


g? 


FIGURA 8.12 Um ataque do homem no meio. 
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que o valor de a ainda seria conhecido somente por Alice). Esse certificado garantiria a Bob que o outro 
participante no Diffie-Hellman é Alice — ou então o outro participante não poderia calcular a chave secreta, 
pois não conhece a. Se os dos participantes tiverem certificados para seus parâmetros Diffie-Hellman, 
eles poderão autenticar um ao outro. Se apenas um tiver um certificado, então apenas este poderá ser 
autenticado. Isso é útil em algumas situações; por exemplo, quando um participante é um servidor Web e 
o outro é um cliente qualquer, o cliente pode autenticar o servidor Web e estabelecer uma chave de sessão 
para obter confidencialidade antes de enviar um número de cartão de crédito ao servidor Web. 


8.4 Exemplos de sistemas 


Neste ponto, já vimos muitos dos componentes necessários para fornecer um ou dois aspectos da 
segurança. Esses componentes incluem algoritmos criptográficos, mecanismos de pré-distribuição 
de chaves e protocolos de autenticação. Nesta seção, vamos examinar alguns sistemas completos que 
utilizam esses componentes. 

Esses sistemas podem ser aproximadamente classificados pela camada de protocolo em que eles 
operam. Os sistemas que operam na camada de aplicação incluem o Pretty Good Privacy (PGP), que 
fornece segurança para o correio eletrônico (e-mail), e Secure Shell (SSH), um mecanismo para login 
remoto seguro. Na camada de transporte, existe o padrão Transport Layer Security (TSL) da IETF e o 
protocolo mais antigo do qual ele foi derivado, o Secure Socket Layer (SSL). Os protocolos do IPsec (IP 
Security), como seu nome indica, operam na camada IP (rede). O 802.11i fornece segurança na camada 
de enlace das redes sem fios. Esta seção descreve os recursos que se destacam em cada uma dessas 
abordagens. 

Você poderia inteligentemente questionar por que a segurança precisa ser fornecida em tantas 
camadas diferentes. Um motivo é que diferentes ameaças exigem diferentes medidas defensivas, e 
isso normalmente se traduz em proteger uma camada diferente do protocolo. Por exemplo, se a sua 
preocupação principal é com uma pessoa na porta ao lado bisbilhotando seu tráfego enquanto ele 
flui entre o seu notebook e o seu ponto de acesso 802.11, então provavelmente desejará segurança na 
camada de enlace. Porém, se você deseja ter toda a certeza de que está conectado ao site Web do seu 
banco, impedindo que todos os dados enviados ao banco sejam lidos por empregados curiosos de algum 
provedor de serviços da Internet, então algo que se estenda da sua máquina até o servidor do banco — 
como a camada de transporte — pode ser o local correto para proteger o tráfego. Como normalmente 
acontece, não existe uma única solução para tudo. 

Os sistemas de segurança descritos a seguir têm a capacidade de variar quais algoritmos criptográficos 
eles utilizam. A ideia de tornar um algoritmo de sistema de segurança independente é muito boa, pois 
você nunca sabe quando seu algoritmo criptográfico favorito provará não ser suficiente para os seus 
propósitos. Seria bom se você pudesse rapidamente mudar para um novo algoritmo sem ter que mudar 
a especificação ou implementação do protocolo. Observe a analogia com a capacidade de trocar chaves 
sem trocar o algoritmo; se um dos seus algoritmos criptográficos demonstrar alguma falha, seria ótimo 
se a sua arquitetura de segurança inteira não precisasse ser imediatamente reprojetada. 


8.4.1 Pretty Good Privacy (PGP) 


O Pretty Good Privacy (PGP) é uma técnica popular para fornecer recursos de segurança para o correio 
eletrônico (e-mail). O PGP oferece autenticação, confidencialidade, integridade de dados e irretratabi- 
lidade. Originalmente idealizado por Phil Zimmerman, ele evoluiu para um padrão da IETF conhecido 
como OpenPGP Conforme vimos na Seção 8.2, o PGP é famoso por usar um modelo de “Rede de 
confiança” para a distribuição de chaves, em vez de uma hierarquia tipo árvore. 

A confidencialidade do PGP e a autenticação do receptor dependem de o receptor de uma mensagem 
de correio eletrônico ter uma chave pública que seja conhecida pelo emissor. Para oferecer autenticação 
eirretratabilidade do emissor, este precisa ter uma chave pública que seja conhecida pelo receptor. Essas 
chaves públicas são pré-distribuídas usando certificados e uma PKI de Rede de confiança, conforme des- 
crevemos na Seção 8.2.1. O PGP admite RSA e DSS para certificados de chave pública. Esses certificados, 
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além disso, especificam quais algoritmos criptográficos são admitidos ou preferidos pelo proprietário 
da chave. Esses certificados fornecem vínculos entre endereços de e-mail e chaves públicas. 

Considere o exemplo de PGP a seguir, sendo usado para fornecer autenticação do emissor e confiden- 
cialidade. Suponha que Alice tenha uma mensagem de correio eletrônico para enviar a Bob. O aplicativo 
PGP de Alice passa pelas etapas ilustradas na Figura 8.13. Primeiro, a mensagem é assinada digitalmente 
por Alice; MDS, SHA-1 e a família SHA-2 estão entre os hashes que podem ser usados na assinatura 
digital. Seu aplicativo PGP então, gera uma nova chave de sessão apenas para esta mensagem; AES e 
3DES estão entre as cifras de chave simétrica admitidas. A mensagem assinada digitalmente é cifrada 
usando a chave de sessão, depois a própria chave de sessão é cifrada usando a chave pública de Bob e 
anexada à mensagem. O aplicativo PGP de Alice a lembra do nível de confiança que ela tinha atribuído 
anteriormente à chave pública de Bob, com base no número de certificados que ela tem para Bob e a 
confiança nos indivíduos que assinaram os certificados. Finalmente, não por segurança, mas porque as 
mensagens de correio eletrônico precisam ser enviadas em ASCII, uma cifração base64 (conforme des- 
crevemos na Seção 9.1.1) é aplicada à mensagem, para convertê-la para uma representação compatível 
com ASCII. Ao receber a mensagem PGP em um e-mail, o aplicativo PGP de Bob inverte esse processo 
passo a passo, para obter a mensagem em texto às claras original e confirmar a assinatura digital de 
Alice — e lembrar a Bob sobre o nível de confiança que ele deposita na chave pública de Alice. 

O correio eletrônico possui características particulares que permitem ao PGP embutir um protocolo 
de autenticação adequado nesse protocolo de transmissão de dados de uma mensagem, evitando a 
necessidade de qualquer troca de mensagens anterior (e deixando de lado algumas das complexidades 
descritas anteriormente na Seção 8.3). A assinatura digital de Alice basta para autenticá-la. Embora não 
haja prova de que a mensagem tem pontualidade, o correio eletrônico legítimo também não tem garantias 
de pontualidade. Também não há prova de que a mensagem é original, mas Bob é um usuário de correio 
eletrônico e provavelmente um ser humano tolerante a falhas, que pode recuperar-se de mensagens 


Olá... = A mensagem em texto às claras 


1) Assinar digitalmente usando 
a chave privada de Alice 


A 


A-B 2) Cifrar usando uma chave de sessão 
de uso único, recém-gerada 


A-B 3) Cifrar a chave de sessão, usando 
a chave pública de Bob, e anexar o 
resultado à mensagem 


4) Usar a cifração base64 para obter uma 


>y p representação compatível com ASCII 


base64 


FIGURA 8.13 Etapas do PGP para preparar uma mensagem para envio por correio eletrônico de Alice para Bob. 
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duplicadas (que, de qualquer forma, também não são fora de questão sob operação normal). Alice pode 
ter certeza que somente Bob poderia ler a mensagem, pois a chave de sessão foi cifrada com sua chave 
pública. Embora esse protocolo não prove a Alice que Bob está realmente lá e recebeu o e-mail, um e-mail 
autenticado de Bob de volta a Alice poderia fazer isso. 

A discussão anterior fornece um bom exemplo de por que os mecanismos de segurança na camada de 
aplicação poderem ser úteis. Somente com um conhecimento completo de como a aplicação funciona é 
que você pode fazer as escolhas certas sobre contra quais ataques se proteger (como o e-mail falsificado) 
e quais ignorar (como e-mail atrasado ou repetido). 


8.4.2 Secure Shell (SSH) A 


VPN 

O Secure Shell (SSH) oferece um serviço de login remoto e tem como finalidade substituir os programas 
menos seguros Telnet e rlogin, usados nos primórdios da Internet. (O SSH também pode ser usado 
para executar comandos remotamente e transferir arquivos, como os comandos rsh e rcp do Unix, res- 
pectivamente, mas vamos nos concentrar em como o SSH permite o login remoto.) O SSH normalmente 
é usado para fornecer forte integridade e autenticação de mensagem entre um cliente e um servidor 
- o cliente SSH é executado no desktop do usuário e o servidor SSH é executado em alguma máquina 
remota, à qual o usuário deseja se conectar —, mas também dá suporte a confidencialidade. O Telnet 
e o rlogin não oferecem essas características. Observe que “SSH” normalmente é usado para se referir 
tanto ao protocolo SSH como às aplicações que o utilizam; você precisa descobrir pelo contexto em 
qual sentido o termo está sendo empregado. 

Para entender melhor a importância do SSH na Internet de hoje, considere alguns dos cenários onde 
ele é usado. Os telecomutadores, por exemplo, normalmente fazem contratos com ISPs que oferecem 
serviços de alta velocidade via modem a cabo ou DSL, e eles usam esses ISPs, bem como cadeias de 
outros ISPs, para alcançar as máquinas operadas por seu empregador. Isso significa que, quando eles 
efetuam o login, suas senhas e todos os dados que enviam ou recebem potencialmente passam por 
inúmeras redes não confiáveis. O SSH fornece um meio de cifrar os dados enviados por essas conexões e 
melhorar o poder do mecanismo de autenticação que eles utilizam para o login. Um uso semelhante do 
SSH é o login remoto em um roteador, talvez para mudar sua configuração ou ler seus arquivos de log; 
claramente, um administrador de rede deseja estar certo de que pode efetuar o login em um roteador 
de modo seguro e que partes não autorizadas não podem efetuar o login nem interceptar os comandos 
enviados para o roteador ou enviados de volta ao administrador. 

A versão mais recente do SSH, a versão 2, consiste em três protocolos: 


e SSH-TRANS: um protocolo da camada de transporte. 
e SSH-AUTH: um protocolo de autenticação. 
e SSH-CONN: um protocolo de conexão. 


Focalizamos os dois primeiros, que estão envolvidos no login remoto. Discutiremos rapidamente a 
finalidade do SSH-CONN ao final desta seção. 

O SSH-TRANS fornece um canal cifrado entre as máquinas cliente e servidor. Ele é executado em 
cima de uma conexão TCP Sempre que um usuário usa uma aplicação SSH para efetuar o login em uma 
máquina remota, o primeiro passo é estabelecer um canal SSH-TRANS entre essas duas máquinas. As 
duas máquinas estabelecem esse canal seguro primeiro pedindo que o cliente autentique o servidor 
usando RSA. Após ser autenticado, cliente e servidor estabelecem uma chave de sessão que eles usarão 
para cifrar quaisquer dados enviados pelo canal. Essa descrição de alto nível passa por cima de vários 
detalhes, incluindo o fato de que o protocolo SSH-TRANS inclui uma negociação do de cifração que os 
dois lados irão utilizar. Por exemplo, o AES normalmente é selecionado. Além disso, o SSH-TRANS inclui 
uma verificação de integridade de mensagens para todos os dados trocados pelo canal. 

A única questão que não podemos passar por cima é o modo como o cliente veio a possuir a chave 
pública do servidor, necessária para autenticar o servidor. Por mais estranho que pareça, o servidor diz 
ao cliente sua chave pública no momento da conexão. Na primeira vez em que o cliente se conecta a um 
servidor em particular, o SSH adverte o usuário de que ele nunca falou com essa máquina antes e pergunta 


408 REDES DE COMPUTADORES ELSEVIER 


se o usuário deseja continuar. Embora sendo algo arriscado de se fazer, como o SSH efetivamente não 
consegue autenticar o servidor, os usuários normalmente respondem “sim” a essa pergunta. A aplicação 
SSH, então, se lembra da chave pública do servidor e, da próxima vez que o usuário se conecta a essa 
mesma máquina, ele compara essa chave salva com aquela com a qual o servidor responde. Se elas forem 
iguais, o SSH autentica o servidor. Porém, se forem diferentes, a aplicação SSH novamente adverte o 
usuário de que há algo errado, e o usuário tem a oportunidade de abortar a conexão. Como alternativa, 
o usuário prudente pode descobrir a chave pública do servidor através de algum mecanismo fora da 
banda, salvá-la na máquina do cliente e assim nunca assumir o risco da “primeira vez”. 

Uma vez estabelecido o canal SSH-TRANS, a próxima etapa é que o usuário realmente se conecte 
à máquina ou, mais especificamente, se autentique com o servidor. O SSH admite três mecanismos 
diferentes para fazer isso. Primeiro, como as duas máquinas estão se comunicando por um canal seguro, 
o usuário pode simplesmente enviar sua senha ao servidor. Isso não é algo seguro de se fazer quando o 
Telnet está sendo usado, pois a senha seria enviada às claras; mas, no caso do SSH, a senha é cifrada no 
canal SSH-TRANS. O segundo mecanismo utiliza a criptografia de chave pública. Isso exige que o usuário 
já tenha colocado sua chave pública no servidor. O terceiro mecanismo, chamado autenticação baseada 
no host, basicamente diz que qualquer usuário afirmando ser fulano de tal dentro de um certo conjunto 
de hosts confiáveis é automaticamente considerado como sendo esse mesmo usuário no servidor. A 
autenticação baseada no host exige que o host do cliente se autentique junto ao servidor, quando eles 
se conectam inicialmente; o SSH-TRANS padrão autentica apenas o servidor, por padrão. 

A coisa principal que você deve reter dessa discussão é que o SSH é uma aplicação relativamente direta 
dos protocolos e algoritmos que já vimos no decorrer deste capítulo. Porém, o que às vezes torna o SSH 
um desafio para se entender são todas as chaves que um usuário precisa criar e gerenciar, considerando 
que a interface exata depende do sistema operacional. Por exemplo, o pacote OpenSSH que é executado 
na maioria das máquinas Unix admite um comando ssh-keygen, que pode ser usado para criar pares de 
chaves pública/privada. Essas chaves são então armazenadas em diversos arquivos no diretório .ssh, 
dentro do diretório home do usuário. Por exemplo, o arquivo /ssh/known. hosts contém registros das 
chaves para todos os hosts onde o usuário efetuou login, o arquivo /.ssh/authorized keys contém as 
chaves públicas necessárias para autenticar o usuário quando ele efetua o login nessa máquina (ou seja, 
elas são usadas no lado do servidor), e o arquivo /.ssh/identity contém as chaves privadas necessárias 
para autenticar o usuário em máquinas remotas (ou seja, elas são usadas no lado do cliente). 

Finalmente, o SSH provou-se ser tão útil como um sistema para a proteção de login remoto que ele 
foi estendido para dar suporte também a outras aplicações, como o envio e recebimento de correio ele- 
trônico. A ideia é executar essas aplicações por um “túnel SSH” seguro. Esse mecanismo é chamado de 
encaminhamento de porta, e utiliza o protocolo SSH-CONN. A ideia é ilustrada na Figura 8.14, em que 
vemos um cliente no host A comunicando-se indiretamente com um servidor no host B pelo encami- 
nhamento do seu tráfego através de uma conexão SSH. O mecanismo é chamado encaminhamento de 
porta porque, quando as mensagens chegam à porta SSH bem conhecida no servidor, o SSH primeiro 
decifra o conteúdo e depois “encaminha” os dados para a porta real em que o servidor está escutando. 
Este é apenas outro tipo de túnel do tipo introduzido na Seção 3.2.9, que neste caso fornece confiden- 
cialidade e autenticação. É possível fornecer uma forma de rede privada virtual (VPN) usando túneis 
SSH dessa maneira. 


Host A Host B 


Aplicação Conexão direta Aplicação 


cliente servidor 


Conexão encaminhada 


SSH SSH . 
FIGURA 8.14 Usando o encaminhamento 


de porta SSH para proteger outras 
aplicações baseadas em TCP. 
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8.4.3 Segurança na camada de transporte (TLS, SSL, HTTPS) 


Para entender os objetivos de projeto e os requisitos do padrão de Segurança da Camada de Transporte 
(TLS — Transport Layer Security) e do Secure Socket Layer (SSL) no qual o TLS é baseado, é importante 
considerar um dos principais problemas que ele tem por finalidade solucionar. Quando a World Wide 
Web tornou-se popular e empresas comerciais começaram a mostrar interesse por ela, ficou claro que 
algum nível de segurança seria necessário para as transações na Web. O exemplo clássico disso é fazer 
compras com cartão de crédito. Existem vários aspectos que devemos nos preocupar quando enviamos 
informações de cartão de crédito a um computador na Web. Primeiro, você poderia se preocupar que a 
informação fosse interceptada em trânsito e, mais tarde, usada para fazer compras não autorizadas. Você 
também poderia se preocupar com os detalhes de uma transação sendo modificada, por exemplo, para 
alterar o valor da compra. E você certamente gostaria de saber se o computador ao qual está enviando 
suas informações de cartão de crédito de fato é aquele pertencente ao vendedor em questão, e não a 
algum intruso. Assim, vemos imediatamente a necessidade de privacidade, integridade e autenticação 
nas transações da Web. A primeira solução bastante utilizada para esse problema foi o SSL, desenvolvida 
originalmente pela Netscape, e que mais tarde formou a base para o padrão TLS da IETE 

Os projetistas do SSL e do TLS reconheceram que esses problemas não eram específicos às transações 
da Web (ou seja, aquelas usando HTTP) e, ao invés disso, montaram um protocolo de uso geral que se 
encontra entre o protocolo de aplicação (por exemplo, HTTP) e o protocolo de transporte (por exem- 
plo, TCP). O motivo para chamar isso de “segurança da camada de transporte” é que, do ponto de vista 
da aplicação, essa camada de protocolo se parece com um protocolo de transporte normal, exceto 
pelo fato de ser seguro. Ou seja, o emissor pode abrir conexões e entregar bytes para transmissão, e a 
camada de transporte segura os levará ao receptor com a confidencialidade, integridade e autenticação 
necessárias. Executando a camada de transporte segura em cima do TCP todos os recursos normais do 
TCP (confiabilidade, controle de fluxo, controle de congestionamento etc.) também são fornecidos à 
aplicação. Esse arranjo de camadas de protocolo é representado na Figura 8.15. 

Quando o HTTP é usado dessa maneira, ele é conhecido como HTTPS (HTTP Seguro). De fato, o HTTP 
em si não muda. Fle simplesmente entrega dados à camada SSL/TLS e recebe dados dela, ao invés de usar 
o TCP Por conveniência, uma porta TCP padrão foi atribuída ao “HTTPS” (443). Ou seja, se você tentar 
se conectar a um servidor na porta TCP 443, é provável que esteja falando com o protocolo SSL/TLS, que 
passará seus dados para o HTTP desde que tudo corra bem com a autenticação e a decifração. Embora 
implementações independentes do SSL/TLS estejam disponíveis, é mais comum que uma implementação 
seja colocada no mesmo pacote que aplicações que precisam dela, principalmente navegadores Web. 

No restante de nossa discussão sobre segurança da camada de transporte, focalizamos o TLS. Embora 
o SSL e o TLS infelizmente não sejam interoperáveis, eles diferem apenas de formas menores, de modo 
que quase toda esta descrição do TLS se aplica ao SSL. 


O protocolo de handshake 
Um par de participantes de TLS negocia em tempo de execução quais algoritmos criptográficos usar. 
Os participantes negociam uma escolha dentre: 


e Hash de integridade de dados (MD5, SHA-1 etc.), usado para gerar os HMACs. 

e Cifra de chave simétrica para prover confidencialidade (entre as possibilidades estão DES, 3DES e AES). 

e Método de estabelecimento de chave de sessão (entre as possibilidades estão Diffie-Hellman, 
Diffie-Hellman fixo e protocolos de autenticação de chave pública usando RSA ou DSS). 


Aplicação (por exemplo, HTTP) 
Camada de transporte segura 
TCP 
IP 


sub-rede FIGURA 8.15 Camada de transporte segura inserida entre as camadas de aplicação e TCP. 
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É interessante que os participantes também podem negociar o uso de um algoritmo de compactação, 
não porque isso fornece quaisquer benefícios à segurança, mas porque isto é fácil de fazer quando você 
está negociando todas essas outras coisas e já decidiu aplicar algumas operações caras por byte sobre 
os dados. 

No TLS, a cifra usada para prover confidencialidade usa duas chaves, uma para cada direção, e seme- 
lhantemente dois vetores de inicialização. De modo semelhante, os HMACSs, são gerados usando chaves 
diferentes para os dois participantes. Assim, independentemente da escolha de cifra e de hash, uma 
sessão TLS requer efetivamente seis chaves. O TLS deriva todas elas a partir de um único segredo mestre 
compartilhado. O segredo mestre é um valor de 384 bits (48 bytes) que, por sua vez, é derivado em parte 
da “chave de sessão” que resulta do protocolo de estabelecimento de chave de sessão do TLS. 

A parte do TLS que negocia as escolhas e estabelece o segredo mestre compartilhado é chamada de 
protocolo de handshake. (A transferência de dados de fato é realizada pelo protocolo de registro do TLS.) O 
protocolo de handshake é em suma um protocolo de estabelecimento de chave de sessão, com um segredo 
mestre no lugar de uma chave de sessão. Como o TLS permite uma escolha entre diferentes abordagens para o 
estabelecimento da chave de sessão, estas exigem variantes de protocolo diferentes, de modo correspondente. 
Além disso, o protocolo de handshake admite uma escolha entre autenticação mútua de ambos os partici- 
pantes, autenticação apenas de um participante (esse é o caso mais comum, como a autenticação de um 
site Web, mas não de um usuário) ou nenhuma autenticação (Diffie-Hellman anônimo). Assim, o protocolo 
de handshake agrupa vários protocolos de estabelecimento de chave de sessão em um único protocolo. 

A Figura 8.16 mostra o protocolo de handshake em um alto nível. O cliente inicialmente envia uma 
lista das combinações de algoritmos criptográficos que ele admite, em ordem decrescente de preferência. 
O servidor responde, fornecendo a única combinação de algoritmos criptográficos que ele selecionou 
dentre aqueles listados pelo cliente. Essas mensagens também contêm um nonce do cliente e um nonce 
do servidor, respectivamente, que serão incorporados na geração do segredo mestre mais adiante. 


Cliente Servidor 





FIGURA 8.16 Protocolo de handshake para estabelecer a sessão TLS. 
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Nesse ponto, a fase de negociação está completa. O servidor agora envia mensagens adicionais 
baseadas no protocolo de estabelecimento de chave de sessão negociado. Isso poderia envolver o envio 
de um certificado de chave pública ou um conjunto de parâmetros do protocolo Diffie-Hellman. Se o 
servidor exigir autenticação do cliente, ele envia uma mensagem separada indicando isso. O cliente, 
então, responde com sua parte do protocolo de estabelecimento de chaves negociado. 

Agora, o cliente e o servidor possuem cada um a informação necessária para gerar o segredo mes- 
tre. A “chave de sessão” que eles trocaram não é realmente uma chave, mas sim o que o TLS chama de 
segredo pré-mestre. O segredo mestre é calculado (usando um algoritmo anunciado) a partir desse se- 
gredo pré-mestre, do nonce do cliente e do nonce do servidor. Usando as chaves derivadas do segredo 
mestre, o cliente então envia uma mensagem que inclui um hash de todas as mensagens de handshake 
anteriores, à qual o servidor responde com uma mensagem semelhante. Isso lhes permite detectar 
quaisquer discrepâncias entre as mensagens de handshake que eles enviaram e receberam, como o que 
resultaria, por exemplo, se um homem no meio modificasse a mensagem inicial do cliente não cifrada 
para enfraquecer suas escolhas de algoritmos criptográficos. 


O protocolo de registro 

Dentro de uma sessão estabelecida pelo protocolo de handshake, o protocolo de registro do TLS 
acrescenta confidencialidade e integridade ao serviço de transporte básico. As mensagens entregues 
pela camada de aplicação são: 


Fragmentadas ou organizadas em blocos de um tamanho conveniente para as etapas seguintes. 
Opcionalmente compactadas. 

Protegidas em termos de integridade usando um HMAC. 

Cifradas usando uma cifra de chave simétrica. 

Passadas à camada inferior (normalmente, TCP) para transmissão. 


Ue W D à 


O protocolo de registro usa um HMAC como autenticador. O HMAC usa qualquer que seja o algo- 
ritmo de hash (MD5, SHA-1 etc.) que foi negociado pelos participantes. O cliente e o servidor possuem 
diferentes chaves para usar ao calcular HMACs, tornando-os ainda mais difíceis de quebrar. Além disso, 
cada mensagem do protocolo de registro recebe um número de sequência, que é incluído quando o 
HMAC é calculado - embora o número de sequência nunca seja explicitado na mensagem. Esse número 
de sequência implícito impede repetições ou reordenações de mensagens. Isso é necessário porque, 
embora o TCP possa entregar mensagens sequenciais e não duplicadas à camada acima dele sob su- 
posições normais, essas suposições não incluem um adversário que possa interceptar mensagens TCP 
modificar mensagens ou enviar mensagens falsas. Por outro lado, são as garantias de entrega do TCP 
que permitem ao TLS contar com o fato de que uma mensagem TLS legítima terá o próximo número 
de sequência implícito na ordem correta. 

Outro recurso interessante do protocolo TLS, que é um recurso muito útil para transações na Web, 
é a capacidade de retomar uma sessão. Para entender a motivação para isso, é útil entender como o 
HTTP utiliza conexões TCP. (Os detalhes do HTTP são apresentados na Seção 9.1.2.) Cada operação 
HTTP como obter uma página de texto ou uma imagem de um servidor, exige que uma nova conexão 
TCP seja aberta. Recuperar uma única página com uma série de objetos gráficos embutidos pode exigir 
muitas conexões TCP Lembre-se, da Seção 5.2, que abrir uma conexão TCP exige uma operação de apre- 
sentação em três vias (three-way handshake) antes que a transmissão de dados possa se iniciar. Quando 
a conexão TCP estiver pronta para aceitar dados, o cliente precisa iniciar o protocolo de handshake TLS, 
o que toma pelo menos outros dois tempos de ida e volta (e consume alguma quantidade de recursos de 
processamento e largura de banda da rede) antes que os dados reais da aplicação possam ser enviados. 
A capacidade de retomada de sessão do TLS alivia esse problema. 

A retomada de sessão é uma otimização do handshake que pode ser usada nos casos onde o cliente 
e o servidor já estabeleceram algum estado compartilhado no passado. O cliente simplesmente inclui 
o ID de sessão de uma sessão estabelecida anteriormente em sua mensagem de handshake inicial. Se o 
servidor descobrir que ainda tem estado para essa sessão, e a opção de retomada foi negociada quando 
essa sessão foi criada originalmente, então o servidor pode responder ao cliente com uma indicação 
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de sucesso, e a transmissão de dados pode começar usando os algoritmos e parâmetros negociados 
anteriormente. Se o ID de sessão não corresponde a qualquer estado de sessão em cache no servidor, 
ou se a retomada não foi permitida para a sessão, então o servidor retornará ao processo de handshake 
normal. 


8.4.4 IP Security (IPsec) 


Provavelmente, o mais ambicioso de todos os esforços para integrar segurança à Internet acontece 
no nível da camada IP O suporte ao IPsec, como a arquitetura é chamada, é opcional no IPv4, mas 
obrigatório no IPv6. 

O IPSec é na realidade um arcabouço (ao contrário de um único protocolo ou sistema) para fornecer 
os serviços de segurança discutidos no decorrer deste capítulo. O IPSec fornece três graus de liberdade. 
Primeiro, ele é altamente modular, permitindo que os usuários (ou, mais provavelmente, os adminis- 
tradores de sistemas) selecionem alguns dentre uma grande variedade de algoritmos de criptografia e 
protocolos de segurança especializados. Segundo, o IPSec permite que os usuários selecionem algumas 
propriedades de segurança a partir de um grande menu de possibilidade, incluindo controle de acesso, 
integridade, autenticação, originalidade e confidencialidade. Terceiro, o IPSec pode ser usado para 
proteger fluxos específicos (por exemplo, pacotes pertencentes a determinada conexão TCP sendo 
enviados entre um par de hosts) ou fluxos amplos (por exemplo, todos os pacotes fluindo entre um par 
de roteadores). 

Quando visto de um nível alto, o IPSec consiste em duas partes. A primeira parte é um par de pro- 
tocolos que implementam os serviços de segurança disponíveis. Eles são o Cabeçalho de Autenticação 
(AH -Authentication Header), que fornece controle de acesso, integridade de mensagem sem conexão, 
autenticação e proteção contra ataques de repetição, e o Encapsulamento de Dados de Segurança 
(ESP — Encapsulating Security Payload), que dá suporte a esses mesmos serviços, mais confidencialidade. 
O AH raramente é usado, de modo que focalizamos o ESP aqui. A segunda parte é o suporte ao geren- 
ciamento de chaves, que se encaixa no protocolo guarda-chuva chamado Protocolo de Gerenciamento 
de Chaves e Associações de Segurança da Internet (ISAKMP - Internet Security Association and Key 
Management Protocol). 

A abstração que une essas duas partes é a Associação de Segurança (AS). Uma AS é uma conexão 
simplex (unidirecional) com uma ou mais propriedades de segurança disponíveis. A segurança de uma 
comunicação bidirecional entre um par de hosts — correspondente a uma conexão TCP por exemplo — 
exige duas AS, um em cada direção. Embora o IP seja um protocolo sem conexão, a segurança depende 
da informação de estado da conexão, como chaves e números de sequência. Quando criado, uma AS 
recebe um número de ID chamado Índice de Parâmetros de Segurança (SPI- Security Parameters Index) 
da máquina receptora. Uma combinação desse SPI com os endereços IP de destino identifica exclusi- 
vamente uma AS. Um cabeçalho ESP inclui o SPI, de modo que o host receptor pode determinar a qual 
AS um pacote recebido pertence e, portanto, quais algoritmos e chaves aplicar ao pacote. 

AS são estabelecidas, negociadas, modificadas e excluídas usando o ISAKMP Ele define formatos de 
pacote para a troca de dados de geração e autenticação de chaves. Esses formatos não são muito interes- 
santes, pois fornecem apenas uma arquitetura — a forma exata das chaves e dos dados de autenticação 
depende da técnica de geração de chave, da cifra e do mecanismo de autenticação que é usado. Além 
disso, o ISAKMP não especifica um protocolo de troca de chaves em particular, embora sugira a Internet 
Key Exchange (IKE) como uma possibilidade, e o IKE seja o que é usado na prática. 

O ESP é o protocolo usado para transportar dados com segurança por um AS estabelecido. No IPv4, o 
cabeçalho ESP vem logo depois do cabeçalho IP; no IPv6, ele é um cabeçalho de extensão. Seu formato 
usa tanto um cabeçalho quanto um rodapé (trailer), como mostra a Figura 8.17. O campo SPI permite 
que o host receptor identifique a associação de segurança à qual o pacote pertence. O campo NumSeq 
protege contra os ataques de repetição. O campo DadosCargaÚtil do pacote contém os dados des- 
critos pelo campo ProxCab. Se confidencialidade for selecionada, então os dados são cifrados usando 
qualquer que seja a cifra associada ao AS. O campo TamPreenchimento registra quantos bytes de preen- 
chimento (padding) foi acrescentado aos dados; o preenchimento às vezes é necessário porque, por 
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SPI FIGURA 8.17 Formato ESP do IPsec. 
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FIGURA 8.18 Um pacote IP com um pacote IP aninhado, encapsulado usando ESP no modo túnel. 


exemplo, a cifra exige que o texto às claras seja um múltiplo de um número de bytes ou para garantir 
que o texto cifrado resultante termine em um limite de 4 bytes. Finalmente, DadosAutenticação trans- 
porta o autenticador. 

O IPsec admite um modo túnel, além do (mais simples) modo transporte. Cada AS opera em um 
dos dois modos. Em um AS no modo transporte, os dados de carga útil do ESP são simplesmente uma 
mensagem para uma camada mais alta, como UDP ou TCP Nesse modo, o IPsec atua como uma camada 
de protocolo intermediária, semelhante ao que o SSL/TLS faz entre o TCP e uma camada mais alta. 
Quando uma mensagem ESP é recebida, sua carga útil é passada ao protocolo de nível mais alto. 

Em uma AS no modo túnel, porém, os dados de carga útil do ESP são eles mesmos um pacote IP como 
na Figura 8.18. A origem e o destino desse pacote IP interior podem ser diferentes daqueles do pacote IP 
mais externo. Quando uma mensagem ESP é recebida, sua carga útil é encaminhada como um pacote 
IP normal. O modo mais comum de usar o ESP é para montar um “túnel IPsec” entre dois roteadores, 
tipicamente agindo como firewalls. Por exemplo, uma empresa querendo ligar duas filiais usando a 
Internet poderia abrir um par de AS no modo túnel entre um roteador em uma filial e um roteador na 
outra filial, conforme discutimos na Seção 3.2.9. Um pacote IP saindo de uma filial seria transformado, 
no roteador de saída, na carga útil da mensagem ESP enviada ao roteador da outra filial. O roteador 
receptor abriria o pacote IP contido na carga útil e o encaminharia para o seu destino verdadeiro. 

Esses túneis também podem ser configurados para usar ESP com confidencialidade e autenticação, 
impedindo assim o acesso não autorizado aos dados que atravessam esse enlace virtual e garantindo 
que nenhum dado espúrio seja recebido na outra extremidade do túnel. Além disso, os túneis podem 
melhorar a confidencialidade do tráfego, pois a multiplexação de vários fluxos por um único túnel 
esconde a informação sobre quanto tráfego está fluindo entre dois sistemas finais em particular. Uma 
rede desses túneis pode ser usada para implementar uma rede privada virtual inteira (ver Seção 3.2.9). 
Os hosts se comunicando por uma VPN não precisam sequer estar cientes de que ela existe. 


8.4.5 Segurança sem fios (802.11) 


Enlaces sem fio (Seção 2.7) são particularmente expostos a ameaças de segurança devido à falta de 
qualquer segurança física no meio. Embora a conveniência do 802.11 tenha estimulado a aceitação 
generalizada desta tecnologia, a falta de segurança tem sido um problema recorrente. Por exemplo, é 
muito fácil para um empregado de uma empresa conectar um ponto de acesso 802.11 à rede corporativa. 
Como as ondas de rádio passam pela maioria das paredes, se o ponto de acesso não tiver as medidas 


414 REDES DE COMPUTADORES ELSEVIER 


de segurança corretas, um atacante, agora, pode ganhar acesso à rede corporativa de fora do prédio. De 
modo semelhante, um computador com um adaptador de rede sem fio dentro do prédio poderia conec- 
tar-se a um ponto de acesso fora do prédio, potencialmente expondo-o ao ataque, sem falar no restante 
da rede corporativa se esse mesmo computador também tiver, digamos, uma conexão Ethernet. 

Consequentemente, tem havido muito trabalho sobre a proteção de enlaces Wi-Fi. De modo sur- 
preendente, uma das primeiras técnicas de segurança desenvolvidas para o 802.11, conhecida como 
Privacidade Equivalente à das Redes com Fios (WEP — Wired Equivalent Privacy), acabou se mostrando 
seriamente falha e facilmente penetrável. 

O padrão IEEE 802.11i fornece autenticação, integridade de mensagem e confidencialidade ao 
802.11 (Wi-Fi) na camada de enlace. O WPA2 (Wi-Fi Protected Access 2) normalmente é usado como 
um sinônimo para 802.11i, embora ele seja tecnicamente uma marca registrada da Wi-Fi Alliance”, que 
certifica a compatibilidade do produto com o 802.11i. 

Por questão de compatibilidade, o 802.11i inclui definições de algoritmos de segurança da primeira 
geração — incluindo WEP - que agora são conhecidos por ter importantes falhas de segurança. Vamos 
tratar aqui dos algoritmos 802.11i, mais novos e mais resistentes. 

A autenticação do 802.11i pode ser feita de dois modos. Em qualquer modo, o resultado final da 
autenticação bem sucedida é uma chave mestra compartilhada entre dois pares. O modo pessoal, 
também conhecido como modo de chave pré-compartilhada (PSK — Pre-Shared Key), fornece segurança 
mais fraca, mas é mais conveniente e econômico para situações como uma rede doméstica 802.11. 
O dispositivo sem fios e o ponto de acesso (AP — Access Point) são pré-configurados com uma pala- 
vra-chave compartilhada — basicamente, uma senha muito longa — da qual a chave mestra é derivada 
criptograficamente. 

O modo de autenticação mais forte do 802.11i é baseado no arcabouço IEEE 802.1X para controlar o 
acesso a uma LAN, que usa um servidor de autenticação (AS — Authentication Server) como na Figura 8.19. 
O AS e o AP devem ser conectados por um canal seguro e poderiam até mesmo ser implementados como 
uma única caixa, mas eles são separados logicamente. O AP encaminha mensagens de autenticação 
entre o dispositivo sem fios e o AS. O protocolo usado para autenticação é chamado de Protocolo de 
Autenticação Extensível (EAP — Extensible Authentication Protocol). O EAP foi projetado para dar suporte 
a vários métodos de autenticação — smart cards, Kerberos, senhas de uso único, autenticação de chave 
pública e assim por diante —, além da autenticação unilateral e mútua. Assim, o EAP é melhor descrito 
como um arcabouço de autenticação do que como um protocolo. Protocolos específicos, compatíveis 
com o EAP são chamados de métodos EAP, e existem muitos deles. Por exemplo, o EAP-TLS é um método 
EAP baseado na autenticação TLS (ver Seção 8.4.3). 

O 802.11i não impõe quaisquer restrições sobre o que o método EAP pode usar como base para a 
autenticação. Porém, ele exige um método EAP que realize a autenticação mútua, pois não somente 
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queremos impedir que um adversário acesse a rede por meio do nosso AP, mas também queremos 
impedir que um adversário engane nossos dispositivos sem fios com um AP falso, malicioso. O resultado 
final de uma autenticação bem-sucedida é uma chave mestra compartilhada entre o dispositivo sem 
fios e o AS, que o AS então transmite para o AP 

Uma das principais diferenças entre o modo mais forte baseado no AS e o modo pessoal mais fraco 
é que o primeiro prontamente admite uma chave exclusiva por cliente. Isso, por sua vez, torna mais 
fácil mudar o conjunto de clientes que podem se autenticar (por exemplo, para revogar o acesso a um 
cliente) sem precisar trocar o segredo armazenado em cada cliente. 

Com uma chave mestra em mãos, o dispositivo sem fios e o AP executam um protocolo de estabe- 
lecimento de chave de sessão chamado apresentação em 4 vias, ou 4-way handshake, para estabelecer 
uma chave transiente entre os pares. Essa chave transiente é, na realidade, uma coleção de chaves que 
inclui uma chave de sessão, chamada chave temporal. Essa chave de sessão é usada pelo protocolo, 
chamado CCMP, que fornece confidencialidade e integridade de dados ao 802.11i. 

O termo CCMP significa CTR (Counter Mode) with CBC-MAC (Cipher-Block Chaining with Message 
Authentication Code) Protocol.!º O CCMP usa AES no modo contador para cifrar os dados e fornecer 
confidencialidade. Lembre-se que, na cifração usando o modo contador, valores sucessivos de um 
contador são incorporados na cifração de blocos sucessivos de texto às claras (Seção 8.1.1). 

O CCMP utiliza um Código de Autenticação de Mensagem (MAC) como autenticador. O algoritmo 
de MAC é baseado no modo CBC (Seção 8.1.1), embora o CCMP não use CBC como forma de cifrar a 
mensagem para prover confidencialidade. Assim, o CBC é executado sem que seja transmitido qualquer 
bloco cifrado pelo CBC, unicamente para que o último bloco cifrado pelo CBC possa ser usado como 
um MAC (apenas seus 8 primeiros bytes são realmente usados). O papel do vetor de inicialização é 
desempenhado por um primeiro bloco construído especialmente, que inclui um número de pacote de 
48 bits — um número de sequência. (O número de pacote também é incorporado na cifração par obter 
confidencialidade e serve para permitir a detecção de ataques de repetição.) Depois disso, o MAC é cifra- 
do juntamente com o texto às claras para impedir ataques de aniversário, que dependem da capacidade 
do atacante em encontrar diferentes mensagens com o mesmo autenticador (Seção 8.1.4). 


8.5 Firewalls 


Embora grande parte deste capítulo tenha se concentrado nos usos da criptografia para fornecer recursos 
de segurança como autenticação e confidencialidade, existe um conjunto inteiro de problemas de seguran- 
ça que não são prontamente tratados por meios criptográficos. Por exemplo, worms e vírus se espalham 
explorando bugs nos sistemas operacionais e programas de aplicação (e às vezes também a ingenuidade 
dos seres humanos), e nenhuma quantidade de criptografia poderá ajudá-lo se a sua máquina tiver vul- 
nerabilidades não corrigidas. Assim, outras técnicas normalmente são usadas para afastar diversas formas 
de tráfego potencialmente perigoso. Os firewalls!! são uma das formas mais comuns de fazer isso. 

Um firewall é um sistema que normalmente é colocado em algum ponto de conectividade entre 
uma instalação que ele protege e o restante da rede, conforme ilustra a Figura 8.20. Ele normalmente 
é implementado como um “aparelho separado” ou como parte de um roteador, embora um “firewall 
pessoal” possa ser implementado em uma máquina do usuário final. A segurança baseada em firewall 
depende de o firewall ser a única conectividade do local com o mundo exterior; não deve haver uma 
forma de contornar o firewall por outros gateways, conexões sem fios ou conexões discadas. A metáfora 
do muro é de certa forma enganosa no contexto das redes, pois uma grande quantidade de tráfego 
atravessa um firewall. Um modo de pensar em um firewall é que, por padrão, ele bloqueia o tráfego a 
menos que esse tráfego tenha permissão específica para passar. Por exemplo, ele poderia filtrar todas 
as mensagens que chegam, exceto aquelas endereçadas a um conjunto em particular de endereços IP 
ou a números de porta TCP em particular. 


Ou seja, o CCMP é um protocolo que combina o Modo Contador (CTR) para a cifração com o algoritmo CBC-MAC 
(Encadeamento de Blocos da Cifra com Código de Autenticação de Mensagens) para autenticar as mensagens. (N.T.) 

HO termo firewall pode ser traduzido para o português como “parede de fogo” ou “parede corta-fogo”, embora o mais 
comum entre os profissionais de segurança seja de fato utilizar o termo em inglês. (N.T.) 
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FIGURA 8.20 Um firewall filtra pacotes fluindo entre uma instalação e o restante da Internet. 


Assim, um firewall divide uma rede em uma zona mais confiável, interna ao firewall, e uma zona 
menos confiável, externa ao firewall.!2 Isso é útil se você não quiser que os usuários externos acessem 
determinado host ou serviço dentro de suas instalações. Grande parte da complexidade vem do fato 
de que você deseja permitir diferentes tipos de acesso a diferentes usuários externos, variando desde o 
público em geral até parceiros de negócios e membros da sua organização localizados remotamente. Um 
firewall também impõe restrições ao tráfego de saída, para impedir certos ataques e limitar as perdas 
se um adversário conseguir obter acesso à rede interna ao firewall. 

Firewalls podem ser usados para criar várias zonas de confiança, por exemplo uma hierarquia de 
zonas cada vez mais confiáveis. Um arranjo comum envolve três zonas de confiança: a rede interna, a 
“zona desmilitarizada”, (DMZ — Demilitarized Zone) e o restante da Internet. A DMZ é usada para manter 
serviços como DNS e servidores de correio eletrônico, que precisam ser acessíveis ao mundo exterior. 
A rede interna e o mundo exterior podem acessar a DMZ, mas os hosts na DMZ não podem acessar a 
rede interna; portanto, um adversário que consiga comprometer um host na DMZ exposta ainda não 
será capaz de acessar a rede interna. A DMZ pode ser restaurada periodicamente para retornar a um 
estado inicial. 

Os firewalls filtram pacotes com base na informação do IP TCP e UDP entre outras coisas. Eles são 
configurados com uma tabela de endereços que caracterizam os pacotes que eles encaminharão ou não. 
Com endereços, queremos dizer mais do que apenas o endereço IP do destino, embora essa seja uma 
possibilidade. Em geral, cada entrada na tabela é uma quádrupla: ela indica o endereço IP e o número 
da porta TCP (ou UDP) da origem e do destino. 

Por exemplo, um firewall poderia ser configurado para filtrar (não encaminhar) todos os pacotes 
correspondentes à seguinte descrição: 


192.12.13.14, 1234, 128.7.6.5, 80 


Esse exemplo diz para filtrar todos os pacotes provenientes da porta 1234 no host 192.12.13.14 en- 
dereçados para a porta 80 no host 128.7.6.5. (A porta 80 é a porta TCP bem conhecida para o HTTP) 
Naturalmente, não é nada prático nomear cada host de origem cujos pacotes você deseja filtrar, de 
modo que os padrões podem incluir símbolos curinga. Por exemplo, 


*,*,128.7.6.5, 80 


diz para filtrar todos os pacotes endereçados à porta 80 em 128.7.6.5, independente do host de origem 
ou da porta que enviou o pacote. Observe que estruturas de endereços como estas exigem que o firewall 
tome decisões de encaminhamento /filtragem com base em números de porta da camada 4, além dos 
endereços de host da camada 3. É por esse motivo que os firewalls da camada de rede às vezes são 
chamados switches da camada 4. 


120 local de um firewall também é considerado a linha divisória entre regiões globalmente endereçáveis e aquelas que usam 
endereços locais. Logo, a funcionalidade da tradução de endereços de rede (NAT - Network Address Translation -, ver Seção 
4.1.3) e a funcionalidade do firewall se encontram no mesmo dispositivo, embora sejam logicamente separadas. 
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Na discussão anterior, o firewall encaminha tudo exceto quando for instruído especificamente para 
filtrar certos tipos de pacotes. Um firewall também poderia filtrar tudo a menos que seja instruído 
explicitamente para encaminhá-lo, ou então usar uma mistura das duas estratégias. Por exemplo, ao 
invés de bloquear o acesso à porta 80 no host 128.7.6.5, o firewall poderia ser instruído a só permitir o 
acesso à porta 25 (a porta de correio SMTP) em determinado servidor de correio, como 


*,*,128.19.20.21,25 


bloqueando todo o tráfego restante. A experiência tem mostrado que os firewalls são constantemente 
configurados de modo incorreto, permitindo o acesso inseguro. Parte do problema é que as regras de 
filtragem podem se sobrepor de maneiras complexas, tornando difícil para um administrador do sistema 
expressar corretamente a filtragem desejada. Um princípio de projeto que melhora a segurança é con- 
figurar um firewall para descartar todos os pacotes exceto aqueles que são permitidos explicitamente. 
Naturalmente, isso significa que algumas aplicações válidas poderiam ser acidentalmente desativadas; 
presume-se que os usuários dessas aplicações por fim percebam o ocorrido e peçam ao administrador 
do sistema para fazer a mudança apropriada. 

Muitas aplicações cliente/servidor atribuem um número de porta dinamicamente ao cliente. Se 
um cliente dentro de um firewall iniciar o acesso a um servidor externo, a resposta do servidor será 
endereçada para a porta atribuída dinamicamente. Isso ocasiona um problema: como o firewall pode 
ser configurado para permitir a passagem do pacote de resposta de um servidor qualquer, mas não 
permitir um pacote semelhante, para o qual não houve solicitação do cliente? Isso não é possível com 
um firewall sem estado, que avalia cada pacote isoladamente. Isso exige um firewall com estado, que 
mantém registros do estado de cada conexão. Um pacote que chega, endereçado a uma porta atribuída 
dinamicamente, teria então sua passagem permitida somente se for uma resposta válida considerando 
o estado atual de uma conexão nessa porta. 

Os firewalls modernos também entendem e filtram com base em muitos protocolos específicos da 
camada de aplicação, como HTTP Telnet ou FTP Eles usam informações específicas desse protocolo, 
como URLs no caso do HTTP para decidir se descartarão uma mensagem. 


8.5.1 Pontos fortes e fracos dos firewalls 


Na melhor das hipóteses, um firewall protege uma rede contra acesso indesejado do restante da In- 
ternet; ele não pode fornecer segurança à comunicação legítima entre o interior e o exterior do firewall. 
Em comparação, os mecanismos de segurança baseados em criptografia, descritos neste capítulo, são 
capazes de fornecer a comunicação segura entre quaisquer participantes em qualquer lugar. Sendo 
esse o caso, por que os firewalls são tão comuns? Um motivo é que os firewalls podem ser implantados 
unilateralmente, usando produtos comerciais já maduros, enquanto a segurança baseada em criptografia 
requer suporte nas duas extremidades da comunicação. Um motivo mais fundamental para o domínio 
dos firewalls é que eles encapsulam a segurança em um local centralizado, desta forma separando a 
segurança do restante da rede. Um administrador do sistema pode gerenciar um firewall para fornecer 
segurança, liberando os usuários e as aplicações dentro do firewall das preocupações com a segurança 
— pelo menos, alguns tipos de preocupações com a segurança. 

Infelizmente, os firewalls possuem limitações sérias. Como um firewall não restringe a comunicação 
entre os hosts que estão dentro do firewall, o adversário que conseguir executar um código interno a 
uma instalação pode acessar todos os hosts locais. Como um adversário poderia entrar no firewall? Ele 
poderia ser um empregado descontente, com acesso legítimo, ou o software do intruso poderia estar 
escondido em algum software instalado a partir de um CD ou obtido da Web. Pode ser possível contornar 
o firewall usando comunicação sem fios ou conexões discadas. 

Outro problema é que quaisquer partes que recebam acesso pelo seu firewall, como parceiros de 
negócios ou empregados trabalhando externamente, tornam-se uma vulnerabilidade de segurança. Se 
a segurança deles não for tão boa quanto a sua, então um adversário poderia penetrar sua segurança 
penetrando primeiro a segurança deles. 

Um dos problemas mais sérios para os firewalls é sua vulnerabilidade à exploração de bugs nas 
máquinas dentro do firewall. Esses bugs são descobertos regularmente, de modo que um administrador 
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do sistema precisa monitorar seus anúncios constantemente. Os administradores constantemente 
falham nesse ponto, pois as brechas de segurança do firewall exploram falhas de segurança que foram 
conhecidas por algum tempo e podem ser facilmente atacadas. 

Malware (de “malicious software”, ou “software malicioso”) é o termo usado para um software que foi 
projetado para atuar em um computador de maneiras ocultas do usuário do computador e indesejadas 
por ele. Vírus, worms e spyware são tipos comuns de malware. (O termo vírus às vezes é usado como 
sinônimo de malware, mas o usaremos no sentido mais estrito, em que se refere a somente um tipo de 
malware em particular.) O código de malwares não precisa ser um código objeto executável nativamente; 
ele poderia ser um código interpretado, como um script ou uma macro executável, como aquelas usadas 
pelo Microsoft® Word. 

Vírus e worms são caracterizados pela capacidade de criar e espalhar cópias de si mesmos; a diferença 
entre eles é que um worm é um programa completo, que se replica, enquanto um vírus é um trecho de 
código que é inserido (e insere cópias de si mesmo) em outra parte de software ou em um arquivo, de 
modo que ele é executado como parte da execução desse software ou como resultado da abertura do 
arquivo. Vírus e worms normalmente causam problemas, como consumir largura de banda de rede, 
como meros efeitos colaterais da tentativa de espalhar cópias de si mesmos. Pior que isso, eles também 
deliberadamente danificam um sistema ou subvertem sua segurança de várias maneiras. Por exemplo, 
eles poderiam instalar uma porta dos fundos (backdoor) — um software que permite o acesso remoto ao 
sistema sem a autenticação normal. Isso poderia levar a um firewall expondo um serviço que deveria 
estar fornecendo seus próprios procedimentos de autenticação, mas que foi subvertido por uma porta 
dos fundos. 

Um Spyware é um software que, sem autorização, coleta e transmite informações privadas sobre 
um sistema computacional ou sobre seus usuários. Normalmente, o spyware é embutido secretamente 
em um programa que, exceto pela presença do spyware, é de fato útil, e é espalhado pelos usuários 
que instalam cópias do mesmo deliberadamente. O problema para os firewalls é que a transmissão da 
informação privada se parece com uma comunicação legítima. 

Uma pergunta natural a ser feita é se os firewalls (ou a segurança criptográfica) poderiam manter 
o malware longe de um sistema em primeiro lugar. A maioria do malware é de fato transmitida pelas 
redes, embora também possa ser transmitida por dispositivos de armazenamento portáteis, como CDs e 
pendrives. Certamente, esse é um argumento em favor do método “bloquear tudo que não for permitido 
explicitamente”, usado por muitos administradores em suas configurações de firewall. 

Uma técnica que é usada para detectar malware é procurar segmentos de código de malware co- 
nhecido, às vezes chamados de assinaturas. Essa abordagem tem seus próprios desafios, pois o malware 
projetado de forma inteligente pode modificar sua representação de várias maneiras. Há também um 
impacto em potencial no desempenho da rede para realizar essa inspeção detalhada dos dados que 
nela ingressam. A segurança criptográfica também não pode eliminar o problema, embora ofereça um 
meio para autenticar o criador de um software e detectar qualquer modificação, como quando um vírus 
insere uma cópia de si mesmo do software. 

Sistemas correlatos aos firewalls são os sistemas conhecidos como Sistemas de Detecção de Intrusão 
(DS -Intrusion Detection Systems) e Sistemas de Previsão de Intrusão (IPS — Intrusion Prevention Systems). 
Esses sistemas tentam identificar atividades anômalas, como uma quantidade de tráfego estranhamente 
grande visando determinado host ou número de porta, por exemplo, e gerar alarmes para os gerentes da 
rede ou talvez ainda tomar uma ação direta para limitar um possível ataque. Embora existam produtos 
comerciais nesse domínio atualmente, esse ainda é um campo em desenvolvimento. 


8.6 Resumo 


Redes como a Internet são compartilhadas por partes com interesses conflitantes, uma situação que 
não foi totalmente prevista nos primórdios das redes. A tarefa de segurança da rede é evitar que algum 
conjunto de usuários espione ou interfira com outros usuários na rede. A confidencialidade é obtida 
cifrando mensagens. A integridade de dados pode ser garantida usando um resumo (hash) criptográfico. 
As duas técnicas podem ser combinadas para garantir a autenticidade de mensagens. 
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As cifras de chave simétrica, como o AES e o 3DES, utilizam a mesma chave secreta para a cifração e 
para a decifração, de modo que o emissor e o receptor precisam compartilhar a mesma chave. As cifras 
de chave pública, como o RSA, utilizam uma chave pública para cifração e uma chave secreta, privada, 
para a decifração. Isso significa que qualquer parte pode usar a chave pública para cifrar uma mensagem 
de modo que ela seja legível apenas pelo dono da chave privada. A técnica mais rápida conhecida para 
quebrar cifras estabelecidas, como AES e RSA, é a busca por força bruta no espaço de chaves possíveis, 
algo que se torna computacionalmente inviável pelo uso de chaves muito grandes. A maior parte das 
situações que exigem cifração para obter confidencialidade usa cifras de chave simétrica devido à 
sua velocidade consideravelmente superior, enquanto as cifras de chave pública normalmente são 
reservadas para autenticação e estabelecimento de chaves de sessão. 

Um autenticador é um valor anexado a uma mensagem para verificar a autenticidade e a integridade 
dos dados da mensagem. Um modo de gerar um autenticador é cifrar um resumo de mensagem que é 
gerado por uma função de hash criptográfica, como o MD5, ou um dos membros da família de hashes 
SHA. Se o resumo de mensagem for cifrado usando a chave privada de uma cifra de chave pública, o 
autenticador resultante é denominado uma assinatura digital, pois a chave pública pode ser usada para 
verificar que somente o dono da chave privada poderia tê-la gerado. Outro tipo de autenticador é um 
Código de Autenticação de Mensagem (MAC - Message Authentication Code), que é gerado por uma 
função semelhante a um hash que usa um valor secreto compartilhado como parâmetro. Um MAC 
baseado em hash é um MAC calculado aplicando-se uma função de hash criptográfico à concatenação 
da mensagem de texto às claras e do valor secreto. 

Uma chave de sessão é usada para proteger um episódio relativamente curto de comunicação. O 
estabelecimento dinâmico de uma chave de sessão depende das chaves pré-distribuídas de vida mais 
longa. A posse de uma chave pública pré-distribuída por uma parte pode ser atestada por um certificado 
de chave pública que é assinado digitalmente por uma parte confiável. Uma Infraestrutura de Chaves 
Públicas (PKI — Public Key Infrastructure) é um esquema completo para certificar esses vínculos entre 
chave e identificador do seu dono, e depende de uma cadeia ou rede de confiança. A pré-distribuição de 
chaves para cifras de chave simétrica é diferente porque os certificados públicos não podem ser usados 
e porque as cifras de chave simétrica precisam de uma chave exclusiva para cada par de participantes. 
Um Centro de Distribuição de Chaves (KDC — Key Distribution Center) é uma entidade confiável que 
compartilha uma chave secreta pré-distribuída entre os participantes, de modo que eles possam usar 
chaves de sessão, e não chaves pré-distribuídas, entre eles. 

A autenticação e o estabelecimento de chave de sessão exigem um protocolo para garantir a pon- 
tualidade e a originalidade das mensagens. Carimbos de tempo ou nonces são usados para garantir que 
as mensagens são recentes. Vimos dois protocolos de autenticação que usam cifras de chave pública, 
um que exigia relógios sincronizados e um que não os exigia. Needham-Schroeder é um protocolo 
para autenticar dois participantes que compartilham, cada um, uma chave de cifra de chave simétrica 
com um KDC. O Kerberos é um sistema de autenticação baseado no protocolo Needham-Schroeder e 
especializado para ambientes cliente/servidor. O protocolo de troca de chaves Diffie-Hellman estabelece 
uma chave de sessão sem chaves pré-distribuídas e sem autenticação. 

Discutimos sobre vários sistemas que fornecem segurança baseada nesses algoritmos criptográficos e 
protocolos. No nível de aplicação, o PGP pode ser usado para proteger mensagens de correio eletrônico 
(e-mail) e o SSH pode ser usado para se conectar com segurança a uma máquina remota. No nível de 
transporte, o TLS pode ser usado para proteger transações comerciais na World Wide Web. No nível de 
rede, o arcabouço do IPsec pode ser usado para proteger a comunicação entre qualquer conjunto de 
hosts ou roteadores na Internet. 

Um firewall filtra as mensagens que passam entre a instalação que ele protege e o restante da rede. 
Firewalls filtram com base em endereços IP TCP e UDP além de campos de alguns protocolos de 
aplicação. Um firewall com estado mantém registro do estado de cada conexão, para que possa per- 
mitir que respostas válidas sejam entregues a portas atribuídas dinamicamente. Embora a segurança 
do firewall tenha limitações importantes, ela tem a vantagem de deslocar alguma responsabilidade 
pela segurança, que sai das mãos dos usuários e das aplicações e vai para as mãos dos administradores 
do sistema. 
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E E O que vem em seguida: Lidando com a segurança E 


Se você perguntar a qualquer pesquisador da Internet “Qual seria o recurso mais importante para 
incluir em uma Internet futura, se pudéssemos começar do zero?”, há uma boa chance de que a 
resposta inclua algo sobre melhor segurança. Um modo de pensar sobre o problema é que a Internet 
foi projetada por uma comunidade muito pequena, que queria acessar os computadores um do outro; 
hoje, a Internet é usada por uma comunidade muito grande, global, incluindo um número razoável 
de criminosos, que também gostariam de ter acesso a muitos outros computadores. Assim, o projeto 
de tornar o acesso aberto a forma padrão certamente não é uma boa opção no mundo de hoje. 

Existem muitas teorias sobre como essa situação poderia ser melhorada. Logicamente, um pro- 
blema é que a Internet é uma parte tão fundamental da vida diária atual que não podemos imaginar 
ela sendo facilmente substituinda por uma nova versão, criada do zero. Porém, existe muita pesquisa 
do tipo “quadro limpo” em andamento, com base na teoria de que trabalhar em uma Internet do 
futuro, não limitada por questões de implantação incremental, poderia levar a algumas ideias que 
poderiam ser aproveitadas na Internet atual. (Ver a seção de Leitura Adicional do Capítulo 3 para 
obter algumas referências.) 

O panorama a curto prazo parece ser no sentido de continuar o jogo de gato e rato que já existe 
há algum tempo. Os firewalls, sistemas de detecção de intrusão e sistemas de mitigação de DoS 
tornam-se mais sofisticados; os invasores encontram novas maneiras de contornar as defesas desses 
sistemas; os sistemas evoluem para se tornarem melhores na defesa contra os novos ataques, e assim 
por diante. No lado positivo, muitos sistemas de segurança funcionam muito bem; não haveria tanto 
comércio eletrônico na Web quanto existe atualmente se não fosse pela eficiência da Transport Layer 
Security (TLS) e todos os métodos criptográficos dos quais este mecanismo depende. 

Uma frase que tem sido usada para descrever uma visão para uma Internet do futuro é “Uma In- 
ternet merecendo a confiança da sociedade”. É claro que atingir essa visão é um desafio significativo, 
e que a proteção de redes será uma área de pesquisa e inovação ainda por um bom tempo. 


Leitura adicional 


Os dois primeiros artigos relacionados à segurança, juntos, fornecem uma boa visão geral do assunto. O artigo de Lampson 

et al. contém um tratamento formal da segurança, enquanto o artigo de Satyanarayanan fornece uma boa descrição de 

como um sistema seguro é projetado na prática. O terceiro artigo fornece uma visão geral e de certa forma alarmante de 

como os worms e vírus se espalham e como um ataque bem planejado poderia ser agilizado. 

Lampson, B. et al. Authentication in distributed systems: theory and practice. ACM Transactions on Computer Systems, 
v. 10, n. 4, p. 265-310, novembro de 1992. 

Satyanarayanan, M. Integrating security in a large distributed system. ACM Transactions on Computer Systems, V. 7, n. 3, 
p. 247-80, agosto de 1989. 

Staniford, S., V. Paxson e N. Weaver. How to Own the Internet in Your Spare Time. USENIX Security Symposium 2002, p. 
149-67. San Francisco, CA, agosto de 2002. 


Existem muitos livros bons abordando toda a gama de questões de segurança da rede. Recomendamos 
Schneier [Sch95], Stallings [Sta03] e Kaufman et al. [KPS02]. Os dois primeiros contêm um tratamento 
abrangente do assunto, enquanto o último fornece uma visão geral bastante agradável de ler do as- 
sunto. A arquitetura IPSec completa é definida como uma série de RFCs: [Ken05al, [Eas05], [MG98a], 
[MG98b], [MD98], [Ken05b] e [Kau05]. O padrão OpenPGP é definido em [Cal07], e o padrão TLS mais 
recente é [DRO8]. Um livro de Barrett e Silverman [Bar01] contém uma descrição minuciosa do SSH. 
Menezes et al. [MvOV96] é uma referência abrangente sobre criptografia (uma cópia pode ser baixada 
gratuitamente pelo URL listado a seguir). 

Uma discussão do problema de reconhecer e defender-se contra ataques de negação de serviço pode 
ser encontrada em Moore et al. [MVS01], Spatscheck e Peterson [SP99] e Qiexh et al. [QPP02]. Técnicas 
recentes, usadas para identificar a origem de ataques, podem ser encontradas nos artigos de Savage 
etal. [SWKAO0] e Snoeren et al. [SPS+01]. A ameaça crescente dos ataques de DDos é discutida por Garber 
[Gar00] e Harrison [Har00], e uma abordagens iniciais de defesa contra tais ataques são relatada em um 
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artigo de Park e Lee [PL01]. Uma técnica nova para prevenção de Dos, que se encontra na categoria de 
“quadro limpo”, é a técnica TVA de Yang et al. [YWA08]. 


Finalmente, recomendamos as seguintes referências vivas: 


e http://www.cert.org/: O site Web do CERT (Computer Emergency Response Team ou Time de 


Resposta a Emergências Computacionais), uma organização voltada para questões de segurança 
da computação. 


e http://www.cacr.math.uwaterloo.ca/hac/: Cópia para download de [MvOV96], uma referência 


abrangente sobre criptografia. 


Exercícios 


1. 


10. 


Procure um utilitário de criptografia (por exemplo, o comando des ou pgp do Unix) no seu 
sistema. Leia sua documentação e faça experimentos com ele. Meça a velocidade com que ele 
pode cifrar e decifrar dados. Essas duas velocidades são iguais? Tente comparar esses resultados 
de tempo usando diferentes tamanhos de chave; por exemplo, compare o AES com o DES triplo. 
Desenhe um diagrama do encadeamento de bloco da cifra conforme descrito na Seção 8.1.1. 
Pesquise sobre o que é um esquema de custódia de chaves (key escrow) ou resgate de chaves (key 
surrender), como, por exemplo, o Clipper. Quais são os prós e contras da custódia de chaves? 
Um bom algoritmo de hash criptográfico deveria produzir saídas aleatórias; ou seja, a 
probabilidade de qualquer valor de hash dado deve ser aproximadamente a mesma de qualquer 
outra para dados de entrada escolhidos aleatoriamente. Qual seria a consequência de usar um 
algoritmo de hash cujas saídas não fossem aleatórias? Considere, por exemplo, o caso onde 
alguns valores de hash têm o dobro de probabilidade de ocorrer do que outros. 

Suponha que Alice use o protocolo de autenticação Needham-Schroeder descrito na Seção 

8.3.3 para iniciar uma sessão com Bob. Suponha ainda que um adversário seja capaz de escutar 

as mensagens de autenticação e, muito depois que a sessão tiver terminado, descubra a chave 

de sessão (não cifrada). Como o adversário enganaria Bob de forma que ele autenticasse 

o adversário como sendo Alice? 

Um mecanismo para resistir a ataques de repetição em mecanismos de autenticação por senha 

é usar senhas de uso único: uma lista de senhas é preparada e, quando senha[N] tiver sido aceita, 

o servidor decrementa N e pede senha[N— 1] da próxima vez. Em N=0, uma nova lista é necessária. 

Esboce um mecanismo pelo qual o usuário e o servidor só precisem se lembrar de uma senha mestra 

sm e tenha disponível localmente um modo de calcular senha[N] = f(sm, N). Dica: Considere que g 

é uma função unidirecional apropriada (por exemplo, MDS) e considere que senhalN]=g"(sm) =g 

aplicado N vezes a sm. Explique por que conhecer senha[N] não ajuda a revelar senha[N — 1). 

Suponha que um usuário empregue senhas de uso único como no exercício anterior (ou, pelo mesmo 

motivo, senhas reutilizáveis), mas que a senha seja transmitida de modo “suficientemente lento”. 

a. Mostre que um adversário pode obter acesso ao servidor remoto com um número de 
tentativas relativamente modesto. (Dica: O adversário inicia as tentativas depois que o 
usuário original digitou tudo menos um caractere da senha.) 

b. A que outros ataques o usuário de senhas de uso único poderia estar sujeito? 

O protocolo de acordo de chaves Diffie-Hellman é vulnerável a um ataque de “homem no meio”, 

como mostramos na Seção 8.3.4 e na Figura 8.12. Esboce como o protocolo Diffie-Helman pode 

ser estendido para proteger contra essa possibilidade. 

Suponha que temos um segredo muito curto s (por exemplo, um único bit ou mesmo um número 

de CPF) e queremos enviar a alguém uma mensagem m agora, que não revele s, mas que possa ser 

usada mais tarde para verificar se conhecíamos s. Explique por que m=MD5(s) ou m= E(s) onde E 

é a função de cifração do RSA não seriam escolhas seguras, e sugira uma escolha melhor. 

Suponha que duas pessoas queiram jogar pôquer pela rede. Para “distribuir” as cartas, elas 

precisam de um mecanismo que escolha de forma justa um número aleatório x entre elas; cada 

parte perderia se a outra parte pudesse influenciar de modo injusto a escolha de x. Descreva 

tal mecanismo. Dica: Você pode considerar que, se uma das duas cadeias de bits x, e x, são 

aleatórias, então o OU exclusivo X=x, O x, é aleatório. 
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11. Estime as probabilidades de encontrar duas mensagens com a mesma soma de verificação 
MDS, dado os números totais de mensagens 2%, 28 e 28, Dica: Esse é novamente o problema 
do aniversário, como no Exercício 48 do Capítulo 2, e novamente a probabilidade de que a 
mensagem k+1 tenha uma soma de verificação diferente de cada uma das k anteriores é 1 — k/2128. 
Porém, a aproximação dada naquela dica, para simplificar o produto, não funciona neste exercício. 
Portanto, em vez disso, tome o log de cada lado e use a aproximação log(l — k/2128) = —J/2128, 

12. Suponha que quiséssemos cifrar uma sessão Telnet com, digamos, 3DES. O Telnet envia muitas 
mensagens de 1 byte, enquanto o DES cifra blocos de 8 bytes de cada vez. Explique como o 3DES 
poderia ser usado com segurança neste caso. 

13. Considere o seguinte protocolo UDP simples (baseado mais ou menos no TFTP conforme 
Request for Comments 1350) para o download de arquivos: 

e Cliente envia uma solicitação de arquivo. 

e Servidor responde com o primeiro pacote de dados. 

e Cliente envia ACK, e os dois prosseguem usando a técnica parar-e-esperar. 

Suponha que cliente e servidor possuem chaves Kç e Ks, respectivamente, e que essas chaves são 

conhecidas por ambos. 

a. Estenda o protocolo de download de arquivo, usando essas chaves e o MDS para fornecer 
autenticação do emissor e integridade de mensagem.º Seu protocolo também deverá ser 
resistente a ataques de repetição. 

b. Como a informação extra no seu protocolo revisado protege contra a chegada de pacotes 
atrasados provenientes de instâncias de conexão anteriores e contra o reinício cíclico do 
número de sequência? 

14. Usando o navegador que você preferir, descubra em que autoridades certificadoras para 
HTTPS ele está configurado para confiar por padrão. Você confia nessas agências? Descubra 
o que acontece quando você desativa a confiança em algumas ou todas essas autoridades 
certificadoras. 

15. Use uma implementação OpenPGP como GnuPG para fazer o seguinte. Observe que nenhuma 
mensagem de e-mail é envolvida — você está trabalhando exclusivamente com arquivos em uma 
única máquina. 

a. Gere um par de chaves pública-privada. 

b. Use sua chave pública para cifrar um arquivo, como se fosse ser seguramente armazenado, e 
depois use sua chave privada para decifrá-lo. 

c. Use seu par de chaves para assinar digitalmente um arquivo não cifrado e depois, como se 
você fosse outra pessoa, verifique sua assinatura usando sua chave pública. 

d. Considere o primeiro par de chaves pública-privada como pertencendo a Alice e gere um 
segundo par de chaves pública-privada, para Bob. Desempenhando o papel de Alice, cifre e 
assine um arquivo destinado a Bob. (Não se esqueça de assinar como Alice, e não como Bob.) 
Depois, desempenhando o papel de Bob, verifique a assinatura de Alice e decifre o arquivo. 

16. Considere uma hierarquia de certificação conforme descrevemos na Seção 8.2.1. Uma CA 
raiz assina um certificado para uma CA de segundo nível, e a CA de segundo nível assina um 
certificado para Alice. Bob tem a chave pública da CA raiz, de modo que ele pode verificar o 
certificado da CA de segundo nível. Por que Bob ainda não poderia confiar que o certificado para 
Alice verdadeiramente estabelece Alice como proprietária da chave pública no certificado? 

17. O PuTTY (pronuncia-se “putty”) é um cliente SSH gratuito e popular — uma aplicação que 
implementa o lado cliente de conexões SSH — para Unix e Windows. Sua documentação pode ser 
acessada via Web. 

a. Como o PuTTY trata da autenticação de um servidor ao qual ele não esteve conectado 
anteriormente? 


Nestes exercícios, suponha que o MDS seja uma função de hash segura. Na realidade, são conhecidos ataques contra o 
MDS que permitem encontrar duas mensagens com o mesmo valor de hash com uma probabilidade muito superior àquela 
ditada pelo problema do aniversário, de modo que seu uso como função de hash é fortemente não recomendado. (N.T.) 





18. 


19. 


20. 


21. 
22. 
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b. Como os clientes são autenticados junto aos servidores? 

c. O PuTTY tem suporte a várias cifras. Como ele determina qual deve ser usada para uma 
conexão em particular? 

d. O PuTTY tem suporte a cifras, como o DES, que poderiam ser consideradas muito fracas para 
algumas — ou todas as — situações. Por quê? Como o PuTTY determina quais cifras são fracas e 
como ele usa essa informação? 

e. Para determinada conexão, o PuTTY permite que um usuário especifique uma quantidade 
máxima de tempo e/ou dados transmitidos após a qual o PuTTY iniciará o estabelecimento 
de uma nova chave de sessão, que a documentação se refere como troca de chave ou rekeying. 
Qual é a motivação por trás desse recurso? 

f. Use o PuTTYgen, o gerador de chaves do PuTTY, para gerar um par de chaves pública-privada 
para uma das cifras de chave pública admitidas pelo PuTTY. 

Suponha que você queira que seu firewall bloqueie todas as conexões Telnet que chegarem, mas 

permita conexões Telnet de saída. Uma abordagem seria bloquear todos os pacotes entrantes 

destinados à porta designada do Telnet (23). 

a. Poderíamos querer bloquear também os pacotes que chegam a outras portas, mas quais 
conexões TCP que chegam precisam ser permitidas a fim de não interferir com o tráfego 
Telnet que sai? 

b. Agora suponha que seu firewall tenha permissão para usar os bits de Flags do cabeçalho TCP 
além dos números de porta. Explique como você pode conseguir o efeito do Telnet desejado 
aqui, enquanto ao mesmo tempo não permite conexões TCP de entrada. 

Suponha que um firewall seja configurado para permitir conexões TCP de saída, mas conexões 

de entrada somente para portas especificadas. O protocolo FTP agora apresenta um problema: 

quando um cliente interno contata um servidor externo, a conexão de controle do TCP de saída 
pode ser aberta normalmente, mas a conexão de dados do TCP tradicionalmente é uma conexão 
de entrada. 

a. Pesquise o protocolo FTP por exemplo, no Request for Comments 959. Descubra como o 
comando PORT funciona. Discuta como o cliente poderia ser programado de modo a limitar 
o número de portas às quais o firewall precisa conceder acesso de entrada. O número dessas 
portas pode ser limitado a um? 

b. Descubra como o comando PASV do FTP pode ser usado para solucionar esse problema de 
firewall. 

Suponha que os roteadores de filtragem estejam organizados como na Figura 8.21; o firewall 

principal é R1. Explique como configurar R1 e R2 de modo que os usuários externos possam 

usar Telnet para a rede 2, mas não para os hosts na rede 1. Para evitar ataques em que o usuário 

“salta” para a rede 1 a partir da rede 2, desative também as conexões Telnet da rede 2 para a 

rede 1. 

Por que um provedor de serviços de Internet poderia querer bloquear certo tráfego de saída? 

Diz-se que o IPsec pode não funcionar com Tradução de Endereços de Rede (NAT — Network 

Address Translation) (RFC 1631). Porém, se IPsec funciona ou não com NAT depende do modo 

do IPsec e do NAT que utilizarmos. Suponha que usemos o NAT verdadeiro, onde somente 





Mundo exterior QI) reae (R2) dida 





FIGURA 8.21 Diagrama para o Exercício 20. 
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endereços IP são traduzidos (sem tradução de porta). O IPsec e o NAT funcionarão em cada um 

dos seguintes casos? Explique por que sim ou por que não. 

a. O IPsec usa modo de transporte ESP 

b. O IPsec usa o modo túnel ESP 

c. E se usarmos a tradução de endereço de porta (PAT — Port Address Translation), também 
conhecida como tradução de endereço de rede e porta (NAPT — Network Address/Port 
Translation) no NAT, onde além de endereços IP os números de porta serão traduzidos para 
compartilhar um endereço IP de fora da rede privada? 


Aplicações 


Agora, isso não é o fim. Nem mesmo é o início do fim. Mas talvez seja o fim do início. 
Winston Churchill 


E E Problema: aplicações precisam de protocolos próprios E 


Começamos este livro falando sobre programas de aplicação — tudo desde navegadores Web até 
ferramentas de videoconferência — que as pessoas querem executar sobre redes de computadores. 
Nos capítulos intermediários, desenvolvemos, um bloco construtivo de cada vez, a infraestrutura 
de rede necessária para tornar tais aplicações possíveis. Agora, fechamos o círculo, voltando 

às aplicações de rede. Essas aplicações são parte protocolo de rede (no sentido de que trocam 
mensagens com seus pares em outras máquinas) e parte programa de aplicação tradicional 

(no sentido de que interagem com a interface do sistema, sistema de arquivos e, por fim, o usuário). 
Este capítulo explora algumas das aplicações de rede mais populares e disponíveis atualmente. 
Examinar as aplicações nos faz compreender a abordagem de sistemas que enfatizamos 

no decorrer deste livro. Ou seja, a melhor maneira de criar aplicações eficazes em rede é 
entender os blocos construtivo que uma rede pode oferece e como esses blocos podem interagir 
uns com os outros. Assim, por exemplo, uma aplicação em rede em particular poderia ter que 
utilizar um protocolo de transporte confiável, mecanismos de autenticação e privacidade e 
capacidades de alocação de recursos da rede subjacente. As aplicações normalmente funcionam 
melhor quando o desenvolvedor de aplicação sabe como utilizar melhor esses mecanismos 

(e também existem muitos contraexemplos de aplicações fazendo mau uso dos mecanismos 

de rede disponíveis). As aplicações normalmente também precisam de seus próprios protocolos, 
em muitos casos usando os mesmos princípios que vimos em nosso exame anterior dos 
protocolos das camadas inferiores. Assim, nosso foco neste capítulo é em como reunir as ideias 

e as técnicas já descritas para criar aplicações de rede eficazes. Em outras palavras, se você 

se imaginar escrevendo uma aplicação para ser usada em rede, então, por definição, você se 
tornará um projetista (e implementador) de protocolos. 

Depois, voltamos nossa atenção para descrever uma série de aplicações de rede, familiares 

ou não tão familiares. Estas variam desde troca de correio eletrônico e navegação na Web 

até aplicações de integração entre empresas, aplicações de multimídia (como vic e vat), 
gerenciamento de um conjunto de elementos de rede, aplicações emergentes de peer-to-peer e 
redes de distribuição de conteúdo. Essa lista de forma alguma é completa, mas serve para ilustrar 
muitos dos princípios fundamentais do projeto e da construção de aplicações. As aplicações 
precisam escolher os blocos construtivos apropriados que estão disponíveis em outras camadas, 
seja dentro da rede ou nas pilhas de protocolo do host, e depois expandir esses serviços básicos 
para oferecer precisamente o serviço de comunicação exigido pela aplicação. 


9.1 Aplicações tradicionais 


Começamos nossa discussão das aplicações focalizando duas das mais populares: a World Wide Web e 
o correio eletrônico (e-mail). De modo geral, essas aplicações empregam o paradigma de solicitação/ 
resposta — os usuários enviam solicitações aos servidores, que então respondem de acordo. Vamos nos 
referir a essas aplicações como “tradicionais” porque elas tipificam o estilo de aplicação que existe 
desde os primeiros dias das redes de computadores (embora a Web seja muito mais nova que o correio 
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eletrônico, ela tem suas raízes nas transferências de arquivos, que são mais antigas). Em comparação, as 
próximas seções examinam uma classe de aplicações que se tornou viável apenas mais recentemente: 
aplicações de streaming (por exemplo, aplicações de multimídia como vídeo e áudio) e várias aplicações 
baseadas em redes sobrepostas (overlay). (Observe que existe uma sobreposição entre essas classes, 
pois você logicamente pode acessar dados de streaming multimídia via Web, mas por enquanto vamos 
focalizar o uso geral da Web para solicitar páginas, imagens etc.) 

Antes de examinarmos de perto cada uma dessas aplicações, existem três pontos gerais que preci- 
samos destacar. O primeiro é que é importante distinguir entre programas de aplicação e protocolos de 
aplicação. Por exemplo, o Protocolo de Transferência de Hipertexto (HTTP — HyperText Transfer Protocol) 
é um protocolo de aplicação que é usado para obter páginas Web de servidores remotos. Pode haver 
muitos programas de aplicação diferentes — ou seja, clientes Web como Internet Explorer, Chrome, Firefox 
e Safari — que oferecem aos usuários estilo e aparência diferentes, mas todos eles utilizam o mesmo 
protocolo HTTP para se comunicarem com os servidores Web pela Internet. Na verdade, é o fato de que 
o protocolo é publicado e padronizado que permite que os programas de aplicação desenvolvidos por 
muitas empresas e indivíduos diferentes interoperem. É assim que muitos navegadores são capazes de 
interoperar com todos os servidores Web (dos quais também existem muitas variedades). 

Esta seção focaliza dois protocolos de aplicação padronizados, bastante utilizados: 


e SMTP: o Protocolo Simples de Transferência de Correio (Simple Mail Transfer Protocol) é usado 
para trocar mensagens de correio eletrônico. 

e HTTP: o Protocolo de Transferência de Hipertexto (HyperText Transfer Protocol) é usado 
para permitir a comunicação entre navegadores Web e servidores Web. 


Também veremos como protocolos de aplicação personalizados são definidos na arquitetura de 
Web Services. 

O segundo ponto é que, como todos os protocolos de aplicação descritos nesta seção seguem o mes- 
mo padrão de comunicação do tipo solicitação/resposta, esperaríamos que todos eles fossem montados 
em cima de um protocolo de transporte RPC (Remote Procedure Call). Porém, isso não acontece, pois 
todos são implementados em cima de TCP Assim, cada protocolo reinventa um mecanismo simples, 
tipo RPC, em cima de um protocolo de transporte confiável (TCP). Dizemos “simples” porque cada 
protocolo não é projetado para dar suporte a chamadas de procedimento remoto arbitrárias, discutidas 
na Seção 5.3, mas sim para enviar e responder a um conjunto específico de mensagens de solicitação. 

Por fim, observamos que muitos protocolos da camada de aplicação, incluindo HTTP e SMTP pos- 
suem um protocolo acompanhante que especifica o formato dos dados que podem ser trocados. Este é 
uma razão pela qual esses protocolos são relativamente simples: grande parte da complexidade é tratada 
nesse documento acompanhante. Por exemplo, o SMTP é um protocolo para a troca de mensagens de 
correio eletrônico, mas a RFC 822 e o MIME (Multipurpose Internet Mail Extensions) definem o formato 
das mensagens de correio eletrônico. De modo semelhante, o HTTP é um protocolo para obter páginas 
Web, mas o HTML (Hyper Text Markup Language) é uma especificação acompanhante que define a 
forma básica dessas páginas. 


9.1.1 Correio eletrônico (SMTP, MIME, IMAP) 


O correio eletrônico (e-mail) é uma das aplicações de rede mais antigas. Afinal, o que poderia ser mais 
natural do que querer enviar uma mensagem ao usuário no outro extremo de um enlace atravessando 
o país, que você acabou de colocar em funcionamento? Na verdade, os pioneiros da ARPANET não idea- 
lizaram o correio eletrônico realmente como uma aplicação-chave quando a rede foi criada — o acesso 
remoto a recursos de computação foi o objetivo principal —, mas essa aplicação se tornou uma aplicação 
útil, que continua a ser extremamente popular. 

Como observamos, é importante (1) distinguir a interface do usuário (ou seja, seu leitor de e-mail) 
dos protocolos de transferência de mensagem subjacentes (como SMTP ou IMAP) e (2) distinguir entre 
esse protocolo de transferência e um protocolo acompanhante (RFC 822 e MIME), que define o formato 
das mensagens sendo trocadas. Vamos começar examinando o formato da mensagem. 
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Formato da mensagem 

A RFC 822 define que as mensagens têm duas partes: um cabeçalho e um corpo. As duas partes são re- 
presentadas em texto ASCII. Originalmente, o corpo era considerado texto simples. Isso ainda acontece, 
embora a RFC 822 tenha sido expandida com o MIME para permitir que o corpo da mensagem transporte 
todos os tipos de dados. Esses dados ainda são representados em texto ASCII, mas, como eles podem 
ser uma versão codificada de, digamos, uma imagem JPEG, ele não será necessariamente legível por 
usuários humanos. Discutiremos mais sobre o MIME um pouco adiante. 

O cabeçalho da mensagem é uma série de linhas terminadas com <CRLF >. (<CRLF> significa 
carriage-return +line-feed,! que são um par de caracteres de controle ASCII normalmente utilizados 
para indicar o final de uma linha de texto.) O cabeçalho é separado do corpo da mensagem por uma 
linha em branco. Cada linha do cabeçalho contém um tipo e um valor separados por um sinal de dois 
pontos. Muitas dessas linhas de cabeçalho são familiares aos usuários, pois eles precisam preenchê-las 
quando redigem uma mensagem de correio eletrônico. Por exemplo, o cabeçalho To: (para) identifica o 
destinatário da mensagem, e o cabeçalho Subject: (assunto) diz algo sobre a finalidade da mensagem. 
Outros cabeçalhos são preenchidos pelo sistema de entrega de correio subjacente. Alguns exemplos são 
Date: (data) - quando a mensagem foi transmitida —, From: (de) — o usuário que enviou a mensagem — e 
Received: (recebido) — cada servidor de correio que tratou dessa mensagem. Naturalmente, existem 
muitas outras linhas de cabeçalho; o leitor interessado deverá consultar a RFC 822. 

A REC 822 foi estendida em 1993 (e atualizada várias vezes desde então) para permitir que mensagens 
de correio eletrônico transportem muitos tipos diferentes de dados: áudio, vídeo, imagens, documentos 
em PDF e assim por diante. O MIME consiste em três partes básicas. A primeira parte é uma coleção de 
linhas de cabeçalho que expandem o conjunto original definido pela RFC 822. Essas linhas de cabeçalho 
descrevem, de várias maneiras, os dados sendo transportados no corpo da mensagem. Eles incluem 
MIME-Version: (a versão do MIME sendo utilizada), Content-Description: (uma descrição em linguagem 
compreensível por humanos do que existe na mensagem, semelhante à linha Subject:), Content-Type: 
(o tipo de dado contido na mensagem) e Content-Transfer-Encoding: (como os dados no corpo da 
mensagem estão codificados). 

A segunda parte é composta de definições para um conjunto de tipos (e subtipos) de conteúdo. Por 
exemplo, o MIME define dois tipos de imagem parada diferentes, indicados como image/gif e image/ 
jpeg, cada um com o significado óbvio. Como outro exemplo, text/plain refere-se ao texto simples que 
você poderia encontrar em uma mensagem puramente de texto, como a própria RFC 822, enquanto 
text/richtext indica uma mensagem que contém texto com “marcações” (por exemplo, texto usando 
fontes especiais, itálico, etc.). Como um terceiro exemplo, o MIME define um tipo application, onde 
os subtipos correspondem à saída de diferentes programas de aplicação (por exemplo, application/ 
postscript e application/msword). 

O MIME também define um tipo multipart, que diz como uma mensagem transportando mais de 
um tipo de dado é estruturada. Isso é como uma linguagem de programação que define tipos básicos 
(por exemplo, números inteiros e de ponto flutuante) e tipos compostos (por exemplo, estruturas e 
vetores). Um subtipo multipart possível é mixed, que diz que a mensagem contém um conjunto de partes 
de dados independentes em uma ordem especificada. Cada parte, então, possui sua própria linha de 
cabeçalho que descreve o tipo dessa parte. 

A terceira parte é uma maneira de codificar os diversos tipos de dados de modo que eles possam 
ser enviados em uma mensagem de correio eletrônico ASCII. O problema é que, para alguns tipos de 
dados (uma imagem JPEG, por exemplo), qualquer byte de 8 bits na imagem pode conter um dos 256 
valores diferentes. Somente um subconjunto desses valores são caracteres ASCII válidos. É importante 
que as mensagens de correio eletrônico contenham apenas ASCII, pois elas poderiam passar por 
uma série de sistemas intermediários (gateways, conforme descritos a seguir) que assumem que toda 
mensagem de correio eletrônico é ASCII, e adulterariam a mensagem se ela tivesse caracteres não 


1Estes termos têm suas origens nas antigas máquinas de escrever. O carriage return (ou retorno de carro) significa 
que o cilindro onde se encontra o papel retorna para a parte mais à esquerda do papel. O line-feed (nova linha) “gira” 
o cilindro, fazendo a passagem para a próxima linha. (N.T.) 
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ASCII. Para resolver esse problema, o MIME utiliza uma codificação direta dos dados binários para o 
conjunto de caracteres ASCII. A codificação é chamada base64. A ideia é mapear cada três bytes dos 
dados binários originais em quatro caracteres ASCII. Isso é feito agrupando-se os dados binários em 
unidades de 24 bits e dividindo cada uma dessas unidades em quatro partes de 6 bits. Cada parte 
de 6 bits é mapeada para um dos 64 caracteres ASCII válidos; por exemplo, 0 é mapeado para A, 1 é 
mapeado para B e assim por diante. Se você examinar uma mensagem que foi codificada usando 
o esquema de codificação base64, notará apenas as 52 letras maiúsculas e minúsculas, os 10 dígitos 
de 0 até 9, e os caracteres especiais +e /. Estes são os primeiros 64 valores no conjunto de caracteres 
ASCII. 

Como um aparte, para facilitar ao máximo a leitura do e-mail para aqueles que ainda insistem em usar 
leitores de e-mail com suporte apenas a texto, uma mensagem MIME que consiste somente em texto 
puro pode ser codificada usando ASCII de 7 bits. Há também uma codificação legível para quando a 
maioria dos dados são ASCII. 

Juntando tudo isso, uma mensagem que contém algum texto puro, uma imagem JPEG e um arquivo 
PostScript seria parecida com isto: 


MIME-Version: 1.0 

Content-Type: multipart/mixed; 

boundary=“------- 417CA6E2DE4ABCAFBC5” 

From: Alice Smith <Alice@cisco.com> 

To: Bob@cs.Princeton.edu 

Subject: material prometido 

Date: Mon, 07 Sep 1998 19:45:19 -0400 

---------: 417CAGEZ2DE4ABCAFBCS 

Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 

Bob, 

Aqui está a imagem jpeg e o rascunho do relatório que prometi. 
--Alice 

---------: 417CAGE2DE4ABCAFBCS 

Content-Type: image/jpeg 
Content-Transfer-Encoding: base64 

... codificação ilegível de uma figura jpeg 

comem 417CAGEZDE4ABCAFBCS 

Content-Type: application/postscript, name=“draft.ps” 
Content-Transfer-Encoding: 7bit 

... codificação ilegível de um documento PostScript 


Neste exemplo, a linha Content-Type no cabeçalho da mensagem diz que essa mensagem contém 
várias partes, cada uma indicada por uma cadeia de caracteres que não aparece nos próprios dados. 
Cada parte, então, possui suas próprias linhas Content-Type e Content-Transfer-Encoding. 


Transferência de mensagem 

Por muitos anos, a maior parte do correio eletrônico passava de um host para outro usando apenas 
SMTP Embora o SMPT continue a desempenhar um papel fundamental, ele agora é apenas um protocolo 
de correio eletrônico dentre vários, sendo que o IMAP (Internet Message Access Protocol ou Protocolo 
Simples de Transferência de Correio) e o POP (Post Office Protocol ou Protocolo de Agência de Correio) 
são outros dois protocolos importantes para recuperar mensagens de correio. Vamos começar nossa 
discussão examinando o SMTP e prosseguindo para o IMAP a seguir. 

Para colocar o SMTP no contexto certo, precisamos identificar os principais participantes do processo. 
Primeiro, os usuários interagem com um leitor de correio quando eles redigem, arquivam, pesquisam e 
leem sua correspondência. Existem inúmeros leitores de correio, assim como existem muitos navega- 
dores Web que podem ser escolhidos. Nos primórdios da Internet, os usuários normalmente efetuavam 
o login na máquina em que residia sua caixa de correio, e o leitor de correio que eles chamavam era um 
programa de aplicação local, que extraía mensagens do sistema de arquivos. Hoje, naturalmente, os 
usuários acessam sua caixa de correio remotamente, a partir de seu notebook ou smartphone; eles não 
efetuam primeiro o login no host que armazena suas mensagens de e-mail (um servidor de correio). Um 
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segundo protocolo de transferência de correio, como POP ou IMAP é usado para obter remotamente o 
e-mail de um servidor de correio para o dispositivo do usuário. 

Segundo, existe um daemon de correio (ou processo de correio) executando em cada host que mantém 
uma caixa de correio. Você pode pensar nesse processo, também chamado de agente de transferência de 
mensagens (MTA — Message Transfer Agent) como desempenhando o papel de uma agência de correio: 
os usuários (ou seus leitores de correio) dão ao daemon as mensagens que eles desejam enviar a ou- 
tros usuários, o daemon usa SMTP sobre TCP para transmitir a mensagem a um daemon executando 
em outra máquina, e o daemon coloca as mensagens recebidas na caixa de correio do usuário (onde 
o leitor de correio desse usuário poderá encontrá-las mais tarde). Como o SMTP é um protocolo que 
qualquer um poderia implementar, teoricamente poderia haver muitas implementações diferentes do 
daemon de correio. Porém, acontece que existem apenas algumas implementações populares, com o 
antigo programa sendmail, implementado originalmente no Berkeley Unix, e o postfix sendo os mais 
utilizados. 

Embora certamente seja possível que o MTA na máquina de um remetente estabeleça uma conexão 
SMTP/TCP com o MTA na máquina do destinatário, em muitos casos a correspondência atravessa um ou 
mais gateways de correio no seu trajeto do host do remetente até o host do destinatário. Assim como os 
hosts finais, esses gateways também executam um processo de agente de transferência de mensagens. 
Não é por acidente que esses nós intermediários são chamados gateways, pois sua tarefa é armazenar e 
encaminhar mensagens de correio eletrônico, semelhante ao modo como um “gateway IP” (ao qual nos 
referimos como um roteador) armazena e encaminha datagramas IP A única diferença é que um gateway 
de correio normalmente coloca mensagens em buffers no disco e está disposto a tentar retransmiti-las 
para a próxima máquina por vários dias, enquanto um roteador IP mantém datagramas em buffers da 
memória e só está disposto a tentar retransmiti-los por uma fração de segundo. A Figura 9.1 ilustra um 
caminho de dois saltos do remetente ao destinatário. 

Você poderia questionar por que os gateways de correio são necessários. Por que o host do remetente 
não pode enviar a mensagem ao host do destinatário? Um motivo é que o destinatário não quer in- 
cluir em seu endereço o host específico no qual ele lê a correspondência. Outro motivo é a escala. Em 
organizações grandes, normalmente acontece que diversas máquinas diferentes mantêm as caixas de 
correio da organização. Por exemplo, a correspondência entregue a Bob Qcs.princeton.edu primeiro é 
enviada a um gateway de correio no departamento de ciência da computação em Princeton (ou seja, 
ao host chamado cs.princeton.edu), e depois é encaminhada — envolvendo uma segunda conexão — à 
máquina específica em que Bob tem uma caixa de correio. O gateway de encaminhamento mantém 
um banco de dados que mapeia usuários à máquina em que sua caixa de correio reside; o remetente 
não precisa saber esse nome específico. (A lista de linhas de cabeçalho Received: na mensagem o 
ajudará a acompanhar os gateways de correio que determinada mensagem atravessou.) Outro motivo, 
particularmente verdadeiro nos primórdios do correio eletrônico, é que a máquina que hospeda a caixa 
de correio de qualquer usuário pode nem sempre estar ativa ou alcançável, situação em que o gateway de 
correio mantém a mensagem até que ela possa ser entregue. 

Independentemente de quantos gateways de correio estejam no caminho, uma conexão SMTP 
independente é usada entre cada host para mover a mensagem para mais perto do destinatário. Cada 
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FIGURA 9.1 Sequência de gateways de correio que armazenam e encaminham mensagens de correio eletrônico. 
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sessão SMTP envolve um diálogo entre os dois daemons de correio, com um atuando como cliente e 
outro atuando como servidor. Várias mensagens poderiam ser transferidas entre os dois hosts durante 
uma única sessão. Como a RFC 822 define mensagens usando ASCII como a representação básica, não 
deve ser surpresa descobrir que o SMTP também é baseado em ASCII. Isso significa que é possível que 
um humano em um teclado finja ser um programa cliente SMTP 

O SMTP é mais bem entendido por meio de um exemplo simples. A seguir está uma troca entre o host 
remetente cs.princeton.edu e o host destinatário cisco.com. Neste caso, o usuário Bob em Princeton 
está tentando enviar mensagens de e-mail aos usuários Alice e Tom, na Cisco. As linhas enviadas por 
cs.princeton.edu aparecem em texto normal, e as linhas enviadas por cisco.com aparecem em itálico. 
As linhas em branco extras foram acrescentadas para tornar o diálogo mais legível. 


HELO cs.princeton.edu 

250 Hello daemon mail.cs.princeton.edu [128.12.169.24] 
MAIL FROM:<Bob(dcs.princeton.edu> 

250 OK 

RCPT TO:<Alice(Dcisco.com> 

250 OK 

RCPT TO:<TomGdcisco.com> 

550 No such user here 

DATA 

354 Start mail input; end with <CRLF>.<CRLF> 
Blah blah blah... 

...etc. etc. etc. 

<CRLF>.<CRLF> 

250 OK 

QUIT 

221 Closing connection 


Como você pode ver, o SMTP envolve uma sequência de trocas entre o cliente e o servidor. Em cada 
troca, o cliente envia um comando (por exemplo, HELO, MAIL, RCPT, DATA, QUIT) e o servidor responde 
com um código (por exemplo, 250, 550, 354, 221). O servidor também retorna uma explicação legível 
aos humanos para o código (por exemplo, No such user here, que indica que o usuário de destino não 
foi encontrado). Nesse exemplo em particular, o cliente primeiro se identifica junto ao servidor com o 
comando HELO. Ele fornece seu nome de domínio como argumento. O servidor verifica se esse nome 
corresponde ao endereço IP sendo usado pela conexão TCP; você notará que o servidor indica esse 
endereço IP na sua resposta de volta ao cliente. O cliente, então, pergunta ao servidor se ele deseja 
aceitar correspondência para dois usuários diferentes; o servidor responde dizendo “sim” para um e 
“não” para o outro. Depois, o cliente envia a mensagem, que é terminada por uma linha com um único 
ponto (“.”) nela. Finalmente, o cliente termina a conexão. 

Naturalmente, existem muitos outros comandos e códigos de retorno. Por exemplo, o servidor pode 
responder ao comando RCPT de um cliente com um código 251, que indica que o usuário não tem uma 
caixa de correio nesse host, mas que o servidor promete encaminhar a mensagem para outro daemon 
de correio. Em outras palavras, o host está funcionando como um gateway de correio. Como outro 
exemplo, o cliente pode enviar uma operação VRFY para verificar o endereço de correio eletrônico de 
um usuário, mas sem realmente enviar uma mensagem ao usuário. 

O único outro ponto de interesse são os argumentos das operações MAIL e RCPT; por exemplo, 
FROM:<BobQcs.princeton.edu> e TO:< Alice O cisco.com >, respectivamente. Estes se parecem muito 
com campos de cabeçalho definidos na RFC 822 e, em certo sentido, eles são. O que realmente acontece 
é que o daemon de correio analisa a mensagem para extrair as informações de que precisa para executar 
o SMTP Diz-se que as informações extraídas formam um envelope para a mensagem. O cliente SMTP 
utiliza esse envelope para parametrizar sua troca com o servidor SMTP Uma nota histórica: o motivo 
para sendmail se tornar tão popular é que ninguém queria reimplementar essa função de análise de 
mensagem. Embora os endereços de correio eletrônico de hoje tenham uma aparência tão agradável 
(por exemplo, Bob O cs.princeton.edu), isso nem sempre foi assim. Antes que qualquer um pudesse estar 
conectado à Internet, não era raro encontrar endereços de correio eletrônico da forma usuárioY%hostO 
sitelvizinho. 
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Leitor de correio 

A etapa final é quando o usuário realmente obtém suas mensagens da caixa de correio, as lê, responde 
a elas e possivelmente salva uma cópia para referência futura. O usuário realiza todas essas ações 
interagindo com um leitor de correio. Como já dissemos, esse leitor originalmente era apenas um pro- 
grama executando na mesma máquina em que a caixa de correio de um usuário reside, situação em 
que ele poderia simplesmente ler o arquivo que implementa a caixa de correio e gravar dados nele. Isso 
era comum antes da era do notebook. Hoje, o usuário acessa sua caixa de correio por uma máquina 
remota, usando outro protocolo, como o Post Office Protocol (POP) ou o Internet Message Access Protocol 
(IMAP). Está além do escopo deste livro discutir os aspectos de interface com o usuário do leitor de 
correio, mas está definitivamente dentro do escopo falar sobre o protocolo de acesso. Em particular, 
vamos considerar o IMAP. 

O IMAP é semelhante ao SMTP de várias maneiras. Ele é um protocolo cliente/servidor executando 
sobre o TCP onde o cliente (executando na máquina de desktop do usuário) envia comandos na forma 
de linhas de texto ASCII terminadas com <CRLF> e o servidor de correio (executando na máquina 
que mantém a caixa de correio do usuário) gentilmente responde. A troca começa com o cliente se 
autenticando e identificando a caixa de correio que deseja acessar. Isso pode ser representado pelo dia- 
grama de transição de estados simples mostrado na Figura 9.2. Nesse diagrama, LOGIN, AUTHENTICATE 
(autenticar), SELECT (selecionar), EXAMINE (examinar), CLOSE (fechar) e LOGOUT (sair) são exem- 
plos de comandos que o cliente pode enviar, enquanto OK é uma resposta possível do servidor. Outros 
comandos comuns são FETCH, STORE, DELETE e EXPUNGE, com os significados óbvios (buscar, 
armazenar, excluir e eliminar). Outras respostas do servidor incluem NO (cliente não tem permissão 
para realizar essa operação) e BAD (comando está mal formado). 


Conexão estabelecida 


| 


Saudação do servidor 














[o (2) (3) 
Não autenticado 
(7) (4) 
y 
Autenticado N] 
(7) (5) (6) 
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(7) 
Y y Y Y 
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Os dois lados fecham a conexão 


(1) conexão sem pré-autenticação (saudação OK) 

(2) conexão pré-autenticada (saudação PREAUTH) 

(3) conexão rejeitada (saudação BYE) 

(4) comando LOGIN ou AUTHENTICATE bem-sucedido 

(5) comando SELECT ou EXAMINE bem-sucedido 

(6) comando CLOSE, ou recusa do comando SELECT ou EXAMINE 

(7) comando LOGOUT, desligamento do servidor ou conexão fechada FIGURA 9.2 Diagrama de transição de estados do IMAP. 
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Quando o usuário pede para buscar (FETCH) uma mensagem, o servidor a retorna em formato MIME 
e o leitor de correio a decodifica. Além da própria mensagem, o IMAP também define um conjunto de 
atributos de mensagem que são trocados como parte de outros comandos, independente da trans- 
ferência da própria mensagem. Os atributos de mensagem incluem informações como o tamanho da 
mensagem, porém, mais interessante que isso, diversos marcadores (flags) associados à mensagem 
(por exemplo, Seen, Answered, Deleted e Recent). Esses marcadores são usados para manter cliente e 
servidor em sincronismo, ou seja, quando o usuário exclui uma mensagem no leitor de correio, o cliente 
precisa informar esse fato ao servidor de correio. Mais tarde, se o usuário decidir eliminar de vez todas 
as mensagens excluídas, o cliente enviará um comando EXPUNGE ao servidor, que sabe como de fato 
remover todas as mensagens excluídas da caixa de correio. 

Finalmente, observe que, quando o usuário responde a uma mensagem ou envia uma nova men- 
sagem, o leitor de correio não a encaminha da máquina do cliente para o servidor de correio usando 
IMAP mas sim SMTP Isso significa que o servidor de correio do usuário é efetivamente o primeiro 
gateway de correio atravessado ao longo do caminho da máquina do cliente até a caixa de correio do 
destinatário. 


9.1.2 World Wide Web (HTTP) 


A World Wide Web foi tão bem-sucedida e tornou a Internet acessível a tantas pessoas que às vezes 
ela parece ser um sinônimo de Internet. De fato, o projeto do sistema que se tornou a Web começou 
por volta de 1989, bem depois que a Internet tinha se tornado um sistema amplamente implantado. O 
objetivo original da Web era encontrar um modo de organizar e recuperar informações, com base em 
ideias sobre hipertexto — documentos interligados - que já existiam desde a década de 1960.2 A ideia 
básica do hipertexto é que um documento pode ser vinculado a outro documento, e o protocolo (HTTP) 
e a linguagem dos documentos (HTML) fossem projetados para cumprir esse objetivo 

Uma forma útil de pensar na Web é como um conjunto de clientes e servidores cooperativos, todos 
falando a mesma linguagem: HTTP A maioria das pessoas é exposta à Web por meio de um programa 
cliente com interface gráfica ou navegador da Web, como Safari, Chrome, Firefox ou Internet Explorer. 
A Figura 9.3 mostra o navegador Firefox em uso, exibindo uma página de informações da Princeton 
University. 

Logicamente, se você quiser organizar informações em um sistema de documentos ou objetos vin- 
culados, precisará inicialmente de um modo de recuperar um documento. Logo, qualquer navegador da 
Web tem uma função que permite que o usuário obtenha um objeto abrindo um URL. Localizadores de 
recursos uniformes (URLs — Uniform Resource Locators) são tão familiares à maioria de nós atualmente 
que é fácil esquecer que eles nem sempre existiram. Eles oferecem informações sobre o local dos objetos 
na Web; eles se parecem com: 


http://www.cs.princeton.edu/index.html 


Se você abrisse esse URL específico, seu navegador da Web abriria uma conexão TCP com o servidor 
Web na máquina chamada www.cs.princeton.edu e imediatamente obteria e exibiria o arquivo chamado 
index.html. A maioria dos arquivos na Web contém imagens e texto, e alguns possuem trechos de áudio 
e vídeo, código etc. Eles frequentemente também incluem URLs que apontam para outros arquivos 
que podem estar localizados em outras máquinas, algo que é o núcleo da parte “hipertexto” do HTTP 
e do HTML. Um navegador Web tem algum modo de reconhecer URLs (geralmente, destacando ou 
sublinhando algum texto) e pedir que eles sejam abertos. Esses URLs embutidos são chamados links 
de hipertexto.” Quando você pedir ao seu navegador Web para abrir um desses URLs embutidos (por 
exemplo, apontando e clicando nele com um mouse), ele abrirá uma nova conexão, obterá e exibirá um 


*Uma pequena história da Web, fornecida pelo consórcio World Wide Web, acompanha suas raízes desde 1945, descrevendo 
vínculos entre documentos de microficha. 

Neste ponto, usamos o termo “link” para indicar um vínculo entre páginas Web, ao contrário de “enlace”, que foi utilizado 
para indicar uma conexão física nas redes de computadores. Ambos, no original, são indicados com o mesmo termo “link”; daí 
a diferenciação neste texto. (N.T.) 
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FIGURA 9.3 O navegador Web Firefox. 


novo arquivo. Isso é chamado de seguir um link. Portanto, fica muito fácil saltar de uma máquina para 
outra por toda a rede, seguindo links para todos os tipos de informações. O fato de haver um meio de 
embutir um link em um documento e permitir que um usuário siga esse link para obter outro documento 
é a base de um sistema de hipertexto. 

Quando você quer exibir uma página, seu navegador (o cliente) obtém a página do servidor usando 
HTTP que é executado em cima do TCP Assim como o SMTP o HTTP é um protocolo orientado a texto. 
Basicamente, cada mensagem HTTP possui o formato geral 


LINHA INICIAL <CRLF> 
CABEÇALHO MENSAGEM <CRLF> 
<CRLF> 

CORPO MENSAGEM <CRLF> 


onde, como antes, <CRLF> significa o par carriage-return/line-feed. A primeira linha (LINHA INI- 
CIAL) indica se essa é uma mensagem de solicitação ou uma mensagem de resposta. Assim, ela iden- 
tifica o “procedimento remoto” a ser executado (no caso de uma mensagem de solicitação) ou o status 
da solicitação (no caso de uma mensagem de resposta). O próximo conjunto de linhas especifica uma 
coleção de opções e parâmetros que qualificam a solicitação ou a resposta. Existem zero ou mais 
dessas linhas de CABEÇALHO MENSAGEM -o conjunto termina com uma linha em branco -, cada 
qual semelhante a uma linha de cabeçalho em uma mensagem de correio eletrônico. O HTTP define 
muitos tipos de cabeçalho possíveis, alguns deles pertencentes a mensagens de solicitação, alguns a 
mensagens de resposta e alguns aos dados transportados no corpo da mensagem. Porém, em vez de 
mostrar o conjunto completo de tipos de cabeçalho possíveis, vamos apresentar apenas alguns exem- 
plos representativos. Finalmente, após a linha em branco vem o conteúdo da mensagem solicitada 
(CORPO MENSAGEM); essa parte da mensagem é onde um servidor colocaria a página solicitada 
ao responder a uma solicitação, e normalmente está vazia para mensagens de solicitação. 
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Tabela 9.1 Operações de solicitação HTTP 








Operação Descrição 

OPTIONS Solicita informações sobre opções disponíveis 

GET Obtém documento identificado no URL 

HEAD Obtém metainformações sobre documento identificado no URL 
POST Fornece informações (por exemplo, anotações) ao servidor 

PUT Armazena documento sob URL especificado 

DELETE Exclui URL especificado 

TRACE Mensagem de solicitação de loopback 

CONNECT Usada por proxies 


Por que o HTTP trabalha em cima do TCP? Os projetistas não precisavam fazer isso dessa maneira, 
mas o TCP oferece uma correspondência muito boa com aquilo que o HTTP requer, particularmente 
o oferecimento de entrega confiável (quem deseja uma página Web com dados faltando?), controle 
de fluxo e controle de congestionamento. Porém, como veremos mais adiante, existem alguns pro- 
blemas que podem surgir com a construção de um protocolo de solicitação /resposta em cima do TCB 
especialmente se você ignorar as sutilezas das interações entre os protocolos das camadas de aplicação 
e de transporte. 


Mensagens de solicitação 

A primeira linha de uma mensagem de solicitação HTTP especifica três coisas: a operação a ser realizada, 
a página Web em que a operação deverá ser realizada, e a versão do HTTP sendo usada. Embora o HTTP 
defina uma grande variedade de operações de solicitação possíveis — incluindo operações de escrita, 
que permitem que uma página Web seja postada em um servidor —, as duas operações mais comuns 
são GET (obter a página Web especificada) e HEAD (buscar informações de status sobre a página Web 
especificada). A primeira, obviamente, é usada quando seu navegador deseja obter e exibir uma página 
Web. A segunda é usada para testar a validade de um link de hipertexto ou para ver se determinada 
página foi modificada desde que o navegador a acessou pela última vez. O conjunto completo de 
operações é resumido na Tabela 9.1. Por mais inocente que pareça, o comando POST possibilita muitos 
danos (incluindo spam) na Internet. 

Por exemplo, a LINHA INICIAL 


GET http://www .cs.princeton.edu/index.html 
HTTP/1.1 


diz que o cliente deseja que o servidor no host www.cs.princeton.edu retorne a página chamada index. 
html. Esse exemplo em particular usa um URL absoluto. Também é possível usar um identificador 
relativo e especificar o nome do host em uma das linhas CABEÇALHO MENSAGEM; por exemplo, 


GET index.html HTTP/1.1 
Host: www.cs.princeton.edu 


Aqui, Host é um dos campos possíveis de CABEÇALHO MENSAGEM. Um dos campos mais in- 
teressantes é lf-Modified-Since (se modificada desde), que dá ao cliente um modo de solicitar uma 
página Web condicionalmente — o servidor só envia a página se ela tiver sido modificada desde a hora 
especificada nessa linha de cabeçalho. 


Mensagens de resposta 

Assim como as mensagens de solicitação, as mensagens de resposta começam com uma única 
LINHA INICIAL. Neste caso, a linha especifica a versão do HTTP sendo usada, um código de três dígitos 
indicando se a solicitação teve sucesso ou não, e uma cadeia de caracteres de texto dando o motivo para 
a resposta. Por exemplo, a LINHA INICIAL 


HTTP/1.1 202 Accepted 





Capítulo 9º Aplicações 435 
PRM 
ELSEVIER 


Tabela 9.2 Cinco tipos de códigos de resultado do HTTP 





Código Tipo Exemplos de motivos 

1xx Informação solicitação recebida, continuando processo 

2xx Sucesso ação recebida com sucesso, entendida e aceita 

3xx Redirecionamento uma ação adicional precisa ser tomada para completar a solicitação 
4xx Erro do cliente solicitação contém sintaxe errada ou não pode ser atendida 

5xx Erro do servidor servidor foi incapaz de processar uma solicitação aparentemente válida 


indica que o servidor foi capaz de satisfazer à solicitação, enquanto 
HTTP/1.1 404 Not Found 


indica que ele não foi capaz de satisfazer à solicitação, pois a página não foi localizada. Existem cinco 
tipos gerais de códigos de resposta, com o primeiro dígito do código indicando seu tipo. A Tabela 9.2 
resume os cinco tipos de códigos. 

Assim como as consequências inesperadas da mensagem de solicitação do tipo POST, às vezes é 
surpreendente como as diversas mensagens de resposta são usadas na prática. Por exemplo, o redirecio- 
namento da solicitação (especificamente, o código 302) é um mecanismo poderoso, que desempenha 
um papel importante nas redes de distribuição de conteúdo (CDNSs - Content Distribution Networks) 
(ver Seção 9.4.3), redirecionando solicitações para um cache nas proximidades. 

Também de forma similar às mensagens de solicitação, as mensagens de resposta podem conter 
uma ou mais linhas de CABEÇALHO MENSAGEM. Essas linhas repassam informações adicionais ao 
cliente. Por exemplo, a linha de cabeçalho Location especifica que o URL solicitado está disponível 
em outro local. Assim, se a página Web do Departamento de Ciência da Computação de Princeton 
tiver mudado de http://www.cs.princeton.edu/index.html para http://nww.princeton.edu/cs/index.html, 
por exemplo, então o servidor no endereço original poderia responder com: 


HTTP/1.1 301 Moved Permanently 
Location: http://www.princeton.edu/cs/index.html 


No caso mais comum, a mensagem de resposta também conterá a página solicitada. Essa página é 
um documento HTML, mas como ela pode transportar dados não de texto (por exemplo, uma imagem 
GIF), ela é codificada usando MIME (ver Seção 9.1.1). Certas linhas do CABEÇALHO MENSAGEM 
contêm atributos do conteúdo da página, incluindo Content-Length (número de bytes do conteúdo), 
Expires (hora em que o conteúdo é considerado antigo) e Last-Modified (hora em que o conteúdo foi 
modificado pela última vez no servidor). 


Identificadores de Recurso Uniformes (URIs) 
Os URLs que o HTTP utiliza como endereços são um tipo de Identificador de Recurso Uniforme (URI- Uni- 
form Resource Identifier). Um URI é uma cadeia de caracteres que identifica um recurso, onde um recurso 
pode ser qualquer coisa que tenha uma identidade, como um documento, uma imagem ou um serviço. 
O formato dos URIs permite que vários tipos de identificadores de recursos mais especializados 
sejam incorporados no espaço de identificadores de URIs. A primeira parte de um URI é um esquema 
que dá nome a um modo particular de identificar um tipo de recurso, como mailto (“mensagem para”) 
para endereços de correio eletrônico ou file (“arquivo”) para nomes de arquivos. A segunda parte de 
um URI, separada da primeira parte por um sinal de dois pontos, é a parte específica do esquema. 
Esse é um identificador de recurso coerente com o esquema na primeira parte, como nos URIs 


mailto: papainoel(O polonorte.org 


e 


file:///C:/algumacoisa.html 
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Cliente Servidor FIGURA 9.4 Comportamento do HTTP 1.0. 
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Um recurso não precisa ser localizável ou acessível. Vimos um exemplo disso anteriormente na Seção 
7.1.3- os espaços de nomes (namespaces) da Linguagem de Marcação Extensível (XML) são identificados 
por URIs que se parecem muito com URLs, mas, no sentido mais estrito, não são localizadores, pois não 
lhe informam como localizar algo; eles simplesmente oferecem um identificador globalmente exclusivo 
para o espaços de nomes. Não existe um requisito de que você deve ser capaz de acessar algo no URI 
alvo indicado pelo espaços de nomes de um documento XML. Veremos outro exemplo de um URI que 
não é um URL na Seção 9.2.1. 


Conexões TCP 
Aversão original do HTTP (1.0) estabelecia uma conexão TCP separada para cada item de dados obtido 
do servidor. Não é muito difícil entender que esse era um mecanismo muito ineficaz. As mensagens de 
estabelecimento e término da conexão tinham de ser trocadas entre o cliente e o servidor mesmo que 
o cliente quisesse apenas verificar se possuía a cópia mais recente de uma página. Assim, obter uma 
página que incluísse algum texto e uma dúzia de ícones ou outros gráficos pequenos resultaria em 13 
conexões TCP separadas sendo estabelecidas e fechadas. A Figura 9.4 mostra a sequência de eventos 
para buscar uma página que possui um único objeto embutido. As linhas coloridas indicam mensagens 
TCP enquanto as linhas pretas indicam as solicitações e respostas HTTP (Alguns dos ACKs TCP não 
aparecem, para evitar que a figura fique muito confusa.) Você pode ver que dois tempos de ida e volta 
são gastos estabelecendo as conexões TCP enquanto outros dois (pelo menos) são gastos obtendo a 
página e a imagem. Além do impacto da latência, também existe o custo de processamento no servidor 
para lidar com o estabelecimento e término extras da conexão TCP 

Para contornar essa situação, o HTTP versão 1.1 introduziu as conexões persistentes — o cliente 
e o servidor podem trocar várias mensagens de solicitação/resposta pela mesma conexão TCP. As 
conexões persistentes possuem duas vantagens. Primeiro, elas obviamente eliminam o sobrecusto 
do estabelecimento da conexão, reduzindo assim a carga no servidor, a carga na rede causada pelos 
pacotes TCP adicionais e o atraso percebido pelo usuário. Segundo, como um cliente pode enviar várias 
mensagens de solicitação por uma única conexão TCP o mecanismo de janela de congestionamento 
do TCP é capaz de operar de forma mais eficiente. Isso porque não é preciso passar pela fase de 
partida lenta para cada página. A Figura 9.5 mostra a transação da Figura 9.4 usando uma conexão 
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persistente no caso onde a conexão já está aberta (possivelmente devido a algum acesso anterior ao 
mesmo servidor). 

Todavia, as conexões persistentes vêm com um preço. O problema é que nem o cliente nem o servidor 
necessariamente sabem por quanto tempo determinada conexão TCP ficará aberta. Isso é especialmente 
crítico para o servidor, que pode ter de manter conexões abertas relativas a milhares de clientes. A 
solução é que o servidor precisa definir um tempo limite e fechar uma conexão se não tiver recebido 
solicitações na conexão por um período de tempo. Além disso, tanto cliente quanto servidor precisam 
observar se o outro lado decidiu fechar a conexão, e precisam usar essa informação como um sinal de 
que também devem fechar seu lado da conexão. (Lembre-se que os dois lados precisam fechar uma 
conexão TCP antes que ela seja completamente terminada.) As preocupações com essa complexidade 
adicional podem ser um motivo pelo qual as conexões persistentes não foram usadas desde o início, 
mas hoje é bastante aceito que os benefícios das conexões persistentes mais do que compensam suas 
desvantagens. 


Caching 
Uma das áreas de pesquisa (e empreendimento) mais ativas na Internet hoje é como colocar páginas 
Web em unidades de armazenamento temporário (cache) de modo eficaz. O uso do cache possui muitos 
benefícios. Do ponto de vista do cliente, uma página que foi obtida de um cache próximo pode ser 
exibida muito mais rapidamente do que se ela tiver de ser obtida no outro lado do mundo. Do ponto de 
vista do servidor, um cache interceptando e respondendo a uma solicitação reduz a carga no servidor. 
O mecanismo de cache pode ser implementado em muitos lugares diferentes. Por exemplo, o nave- 
gador de um usuário pode colocar páginas acessadas recentemente em cache, e simplesmente exibir 
a cópia em cache se o usuário visitar a mesma página novamente. Como outro exemplo, uma empresa 
pode dar suporte a um único cache para toda a empresa. Isso permite que os usuários aproveitem 
páginas baixadas anteriormente por outros usuários. Mais perto do meio da Internet, os ISPs (provedores 
de serviço de Internet) podem manter páginas em cache. Observe que, no segundo caso, os usuários 
dentro das instalações da empresa provavelmente sabem que máquina está mantendo páginas em 
cache para a empresa, e eles configuram seus navegadores para que se conectem diretamente ao host 
fazendo o cache. Esse nó às vezes é chamado de proxy. Em comparação, as empresas que se conectam 
ao ISP provavelmente não sabem que o ISP está mantendo páginas em cache. Simplesmente, as soli- 
citações HTTP vindas de várias instalações empresariais passam por um roteador em comum no ISP 
Esse roteador pode analisar a mensagem de solicitação e examinar o URL da página solicitada. Se ele 
tiver a página em seu cache, ele a retorna. Se não, ele encaminha a solicitação ao servidor e espera a 
resposta retornar na outra direção. Quando isso acontece, o roteador salva uma cópia na esperança de 
que possa usá-la para satisfazer a uma solicitação futura.“ 


“Existem muitos problemas com esse tipo de mecanismo de cache, indo de questões técnicas a regulatórias. Um exemplo 
de um desafio técnico é o efeito de caminhos assimétricos, quando a solicitação para o servidor e a resposta ao cliente não 
seguem a mesma sequência de saltos no roteamento. 
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Não importando onde as páginas são mantidas em cache, a capacidade de manter páginas Web 
em cache é tão importante que o HTTP foi projetado para facilitar a tarefa. O truque é que o cache 
precisa se certificar de não estar respondendo com uma versão desatualizada da página. Por exemplo, 
o servidor atribui uma data de expiração (o campo Expires no cabeçalho) a cada página que envia de 
volta ao cliente (ou a um cache entre o servidor e o cliente). O cache se lembra dessa data e sabe que 
não precisa verificar novamente a página toda vez que ela for solicitada, até que a data de expiração 
tenha passado. Depois desse momento (ou se esse campo de cabeçalho não estiver definido), o cache 
pode usar a operação HEAD ou GET condicional (GET com a linha de cabeçalho If-Modified-Since) para 
verificar se ele tem a cópia mais recente da página. Em geral, existe um conjunto de diretivas de cache 
que precisam ser obedecidas por todos os mecanismos de cache ao longo da cadeia de solicitação/ 
resposta. Essas diretivas especificam se um documento pode ou não ser mantido em cache, por quanto 
tempo ele pode ser mantido, ou quanto um documento precisa ser recente e assim por diante. Veremos 
o assunto relacionado das CDNSs - que são efetivamente caches distribuídos — na Seção 9.4.3. 


9.1.3 Web Services 


Até aqui, nos concentramos nas interações entre um ser humano e uma máquina. Por exemplo, um ser 
humano usa um navegador Web para interagir com um servidor, e a interação prossegue em resposta à 
entrada do usuário (por exemplo, clicando em links). Porém, existe cada vez mais demanda por interação 
direta entre computadores. E assim como as aplicações descritas anteriormente precisam de protocolos, 
as aplicações também precisam de protocolos para se comunicarem diretamente umas com as outras. 
Concluímos esta seção examinando os desafios da criação de diversos protocolos de aplicação para 
aplicação e algumas das soluções propostas. 

Grande parte da motivação para permitir a comunicação direta entre aplicações vem do mundo dos 
negócios. Historicamente, as interações entre as empresas — comerciais ou outras organizações — têm 
envolvido algumas etapas manuais, como o preenchimento de um formulário de pedido ou uma ligação 
telefônica para determinar se algum produto está disponível no estoque. Mesmo dentro de uma única 
empresa, é comum ter etapas manuais entre sistemas de software que não são capazes de interagir 
diretamente, pois foram desenvolvidos independentemente um do outro. Cada vez mais, essas interações 
manuais estão sendo substituídas pela interação direta entre aplicações. Uma aplicação de geração de 
pedidos na empresa À enviaria uma mensagem a uma aplicação de atendimento de pedidos na empresa 
B, que responderia imediatamente indicando se o pedido pode ser atendido. Se o pedido não puder 
ser atendido por B, a aplicação em A imediatamente fará o pedido junto a fornecedor ou solicitará um 
orçamento de diversos fornecedores. 

Aqui está um exemplo simples daquilo que estamos falando. Suponha que você compre um livro em 
um revendedor on-line, como a Amazon.com. Quando o seu livro tiver sido entregue, a Amazon poderá 
lhe enviar um número de acompanhamento por e-mail, e depois você poderá consultar o site da trans- 
portadora — talvez, http://www.fedex.com — e rastrear o pacote. Porém, você também pode rastrear seu 
pacote diretamente pelo site Amazon.com. Para que isso seja possível, a Amazon precisa ser capaz de 
enviar uma consulta à FedEx, em um formato que a FedEx entenda, interpretar o resultado e exibi-lo 
em uma página Web que contenha outras informações sobre o seu pedido. Por trás da experiência que o 
usuário tem de obter toda a informação sobre o pedido ao mesmo tempo na página Web da Amazon.com 
está o fato de que Amazon e FedEx precisaram ter um protocolo para trocar as informações necessárias 
para rastrear as entregas- chame isso de Protocolo de Rastreamento de Entregas. Vamos deixar claro 
que existem tantos protocolos desse tipo em potencial que é melhor termos algumas ferramentas para 
simplificar a tarefa de especificá-los e montá-los. 

As aplicações de rede, até mesmo aquelas que cruzam as fronteiras de uma organização, não são 
novas — correio eletrônico e navegação Web cruzam essas fronteiras. O que é novo sobre esse problema 
é a escala. Não a escala no que se refere ao tamanho da rede, mas a escala no número de tipos diferentes 
de aplicações de rede. Tanto as especificações do protocolo quanto as implementações desses proto- 
colos para aplicações tradicionais, como correio eletrônico e transferência de arquivos, normalmente 
têm sido desenvolvidas por um pequeno grupo de especialistas em rede. Para permitir que um grande 
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número de aplicações de rede em potencial sejam desenvolvidas rapidamente, foi necessário chegar a 
algumas tecnologias que simplificam e automatizam a tarefa de projeto e implementação de protocolos 
de aplicação. 

Duas arquiteturas foram defendidas como soluções para esse problema. Ambas as arquiteturas são 
chamadas de Web Services (“Serviços Web”), cujo nome vem do termo usado para aplicações individuais 
que oferecem um serviço acessível remotamente às aplicações cliente para formar aplicações de rede.” 
Os termos usados como abreviação informal para distinguir as duas arquiteturas de Web Services são 
SOAP e REST (daí o debate “SOAP versus REST”). Vamos discutir os significados técnicos desses termos 
em breve. 

A abordagem da arquitetura SOAP para o problema é viabilizar, pelo menos em teoria, a geração 
de protocolos que sejam personalizados para cada aplicação de rede. Os principais elementos desta 
abordagem são um arcabouço para a especificação de protocolos, kits de ferramenta de software para 
gerar automaticamente implementações de protocolo a partir das especificações, e especificações 
parciais modulares que podem ser reutilizadas entre os protocolos. 

A abordagem da arquitetura REST para o problema é considerar Web Services individuais como 
recursos da World Wide Web -identificados por URIs e acessados via HTTP Basicamente, a arquitetura 
REST é simplesmente a arquitetura da Web. Os pontos fortes da arquitetura da Web incluem estabilidade 
e uma escalabilidade demonstrada (no sentido do tamanho da rede). Pode ser considerada uma defi- 
ciência o fato de que o HTTP não é muito adequado para o estilo usual para chamadas de um serviço 
remoto, seja ele o procedural ou o orientado a operação. Porém, os defensores do REST argumentam 
que serviços complexos podem, apesar de tudo, ser expostos usando um estilo mais orientado a dados 
ou de passagem de documentos, para o qual o HTTP é bem adequado. 

Embora as duas arquiteturas estejam sendo ativamente adotadas, elas ainda são muito novas para que 
tenhamos muitos dados empíricos sobre seu uso no mundo real. Uma arquitetura pode vir a se tornar 
dominante, ou então elas podem se juntar de alguma maneira, ou podemos descobrir que uma arquite- 
tura é mais adequada para certos tipos de aplicações, enquanto a outra é melhor para outros tipos. 


Protocolos de aplicação personalizados (WSDL, SOAP) 

A arquitetura chamada informalmente de SOAP é baseada na Linguagem de Descrição de Web Services 
(WSDL — Web Services Description Language) e no SOAP. Esses dois padrões são publicados pelo World 
Wide Web Consortium (W3C). Essa é a arquitetura que as pessoas normalmente querem dizer quando 
usam o termo Web Services sem qualquer qualificador. Como esses padrões ainda estão em evolução, 
nossa discussão aqui é efetivamente uma imagem instantânea do cenário atual. 

WSDL e SOAP são arcabouços para especificar e implementar protocolos de aplicação e protocolos de 
transporte, respectivamente. Eles geralmente são usados em conjunto, embora isso não seja estritamente 
exigido. A WSDL é usada para especificar detalhes específicos da aplicação, como quais operações são 
admitidas, os formatos dos dados a serem passados para a aplicação ou que são respondidos por essas 
operações, e se uma operação envolve uma resposta. O papel do SOAP é facilitar a definição de um 
protocolo de transporte exatamente com a semântica desejada, considerando recursos do protocolo 
tais como confiabilidade e segurança. 

Tanto a WSDL quanto o SOAP consistem basicamente em uma linguagem de especificação de 
protocolos. As duas linguagens são baseadas na XML (Seção 7.1.3), visando tornar as especificações 
acessíveis a ferramentas de software como compiladores stub e serviços de diretório. Em um mundo de 
muitos protocolos personalizados, o suporte à geração automática de implementações é decisivo para 
evitar o esforço de implementar cada protocolo manualmente. O software de suporte geralmente toma 
a forma de kits de ferramentas e servidores de aplicação desenvolvidos por fornecedores terceirizados, 
o que permite que os desenvolvedores de Web Services individuais focalizem mais o problema comercial 
que eles precisam solucionar (como rastrear o pacote comprado por um cliente). 


“Infelizmente, o nome Web Services é tão genérico que pode, de modo enganoso, dar a entender que ele inclui qualquer 
tipo de serviço associado à Web. 

Embora o nome SOAP tenha sido originado como um acrônimo, ele oficialmente não tem mais qualquer significado 
por extenso. 
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Definindo protocolos de aplicação 

AWSDL escolheu um modelo de operação procedural para protocolos de aplicação. Uma interface abs- 
trata de Web Services consiste em um conjunto de operações nomeadas, cada uma representando uma 
interação simples entre um cliente e o Web Service. Uma operação é semelhante a um procedimento 
que pode ser chamado remotamente em um sistema de RPC. Um exemplo do WSDL Primer do W3C é 
um Web Service de reserva em hotel com duas operações, CheckAvailability (verificar disponibilidade) 
e MakeReservation (fazer reserva). 

Cada operação especifica um padrão de troca de mensagens (MEP — Message Exchange Pattern) que 
define a sequência em que as mensagens devem ser transmitidas, incluindo as mensagens de falha a 
serem enviadas quando um erro perturba o fluxo das mensagens. Vários MEPs são predefinidos, enovos 
MEPs personalizados podem ser definidos, mas parece que, na prática, apenas dois MEPs estão sendo 
usados: In-Only (uma única mensagem do cliente ao serviço) e In-Out (uma solicitação do cliente e 
uma resposta correspondente do serviço). Esses padrões devem ser bastante familiares, e sugerem que 
os custos de dar suporte a flexibilidade no MEP talvez sejam superiores aos benefícios. 

Os MEPs são modelos que possuem espaços reservados ao invés de tipos ou formatos de mensagem 
específicos, de modo que parte da definição de uma operação envolve especificar quais formatos de 
mensagem mapear para os espaços reservados no padrão. Os formatos de mensagem não são definidos no 
nível de bit que é típico dos protocolos que discutimos. Ao invés disso, eles são definidos como um modelo 
de dados abstrato usando um XML Schema (Seção 7.1.3). O XML Schema fornece um conjunto de tipos de 
dados primitivos e formas de definir tipos de dados compostos. Os dados em conformidade com o formato 
definido por um XML Schema - seu modelo de dados abstrato — podem ser representados concretamente 
usando XML, ou então podem usar outra representação, como a representação “binária” Fast Infoset. 

OWSDL separa muito bem as partes de um protocolo que podem ser especificadas de forma abstrata — 
operações, MEPs, formatos de mensagem abstrata — das partes que devem ser concretas. A parte concreta 
da WSDL especifica um protocolo subjacente, como os MEPs são mapeados nele e qual representação 
em nível de bit é usada para mensagens na rede. Essa parte da especificação é conhecida como vínculo, 
embora ela seja mais bem descrita como uma implementação, ou um mapeamento para uma implemen- 
tação. AWSDL possui vínculos predefinidos para protocolos baseados em HTTP e SOAP com parâmetros 
que permitem que o projetista do protocolo faça ajustes finos ao mapeamento para esses protocolos. 
Existe um arcabouço para definir novos vínculos, mas os protocolos SOAP são dominantes. 

Um aspecto decisivo de como a WSDL alivia o problema de especificar grandes quantidades de 
protocolos é através da reutilização daquilo que são basicamente módulos de especificação. A especifi- 
cação WSDL de um Web Service pode ser composta de vários documentos WSDL, e documentos WSDL 
individuais também podem ser usados em outras especificações de Web Services. Essa modularidade 
facilita o desenvolvimento de uma especificação e também garante que, se duas especificações preci- 
sarem ter alguns elementos que são idênticos (por exemplo, de modo que possam ser suportadas pela 
mesma ferramenta), então esses elementos devem ser realmente idênticos. Essa modularidade, junto 
com as regras padrão da WSDL, também ajuda a impedir que as especificações se tornem extremamente 
extensas para projetistas de protocolo humanos. 

A modularidade da WSDL deve ser familiar a qualquer um que já tenha desenvolvido algum software 
razoavelmente grande. Um documento WSDL não precisa ser uma especificação completa; por exem- 
plo, ele poderia definir um único formato de mensagem. As especificações parciais são identificadas 
exclusivamente usando espaços de nomes XML (Seção 7.1.3); cada documento WSDL especifica o 
URI de um espaço de nomes de destino, e quaisquer novas definições no documento são nomeadas 
no contexto desse espaço de nomes. Um documento WSDL pode incorporar componentes de outro, 
incluindo o segundo documento se ambos compartilharem o mesmo espaços de nomes de destino ou 
importando-o se os espaços de nomes de destino forem diferentes. 


Definindo protocolos de transporte 

Embora o SOAP às vezes, seja chamado de protocolo, ele é considerado mais como um arcabouço para 
definição de protocolos. Conforme a especificação do SOAP 1.2 explica, “O SOAP fornece um arcabouço 
de mensagem simples cuja funcionalidade central sem preocupa em oferecer extensibilidade”. O SOAP 
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usa muitas das mesmas estratégias da SWDL, incluindo formatos de mensagem definidos usando XML 
Schema, vínculos com protocolos básicos, Message Exchange Patterns e elementos reutilizáveis da 
especificação, identificados usando espaços de nomes XML. 

O SOAP é usado para definir protocolos de transporte exatamente com os recursos necessários para 
dar suporte a um protocolo de aplicação em particular. O SOAP visa tornar viável definir muitos desses 
protocolos por meio do uso de componentes reutilizáveis. Cada componente captura a informação 
de cabeçalho e a lógica que entram na implementação de um recurso em particular. Para definir um 
protocolo com um conjunto de recursos, basta escrever os componentes correspondentes. Vejamos 
mais de perto esse aspecto do SOAP. 

O SOAP 1.2 introduziu uma abstração de recurso, que a especificação descreve desta forma: Um 
recurso SOAP é uma extensão do arcabouço de mensagens SOAP Embora o SOAP não imponha restrições 
sobre o escopo em potencial desses recursos, alguns recursos de exemplo podem incluir “confiabilidade”, 
“segurança”, “correlação”, “roteamento” e padrões de troca de mensagem (MEPs), como comunicações de 
solicitação/resposta, unidirecionais e peer-to-peer. Uma especificação de recurso SOAP precisa incluir: 


e Um URI que identifique o recurso. 

e Ainformação de estado e o processamento, descritos de forma abstrata, que é necessário em cada 
nó SOAP para implementar o recurso. 

e Ainformação a ser repassada para o próximo nó. 

e (Seo recurso é um MEP) o ciclo de vida e relacionamentos temporais/causais das mensagens 
trocadas — por exemplo, respostas vêm após as solicitações e são enviadas a quem originou 
a solicitação. 


Observe que essa formalização do conceito de um recurso de protocolo é de um nível um tanto 
baixo; ela é quase um projeto. 

Dado um conjunto de recursos, existem duas estratégias para definir um protocolo SOAP que os 
implemente. Uma delas é pela disposição em camadas: vincular o SOAP a um protocolo básico de tal 
modo que ele derive os recursos. Por exemplo, poderíamos obter um protocolo de solicitação /resposta 
por meio da vinculação do SOAP ao HTTP com uma solicitação SOAP em uma solicitação HTTP e uma 
resposta SOAP em uma resposta HTTP Como esse é um exemplo muito comum, acontece que SOAP 
possui um vínculo predefinido com o HTTP; novos vínculos podem ser definidos usando o arcabouço 
de vínculos do protocolo SOAP (SOAP Protocol Binding Framework). 

A segunda e mais flexível forma de implementar recursos envolve blocos de cabeçalho. Uma mensagem 
SOAP consiste em um Envelope, que contém um Cabeçalho que contém blocos de cabeçalho, e um Corpo, 
que contém a carga útil destinada ao receptor final. Essa estrutura de mensagem é ilustrada na Figura 9.6. 

Neste ponto, deve ser familiar a noção de que certas informações de cabeçalho correspondem a 
determinados recursos. Uma assinatura digital é usada para implementar a autenticação, um número 
de sequência é usado para prover confiabilidade e uma soma de verificação é usada para detectar 
modificações na mensagem. Um bloco de cabeçalho SOAP tem por finalidade encapsular a informação 
de cabeçalho que corresponde a determinado recurso. A correspondência nem sempre é um para um, 
pois vários blocos de cabeçalho poderiam estar envolvidos em um único recurso, ou um único bloco 


Envelope 


Cabeçalho 
Bloco de cabeçalho 


Bloco de cabeçalho 


Corpo 


FIGURA 9.6 Estrutura de mensagem SOAP. 
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de cabeçalho poderia ser usado em vários recursos. Um módulo SOAP é uma especificação da sintaxe 
e da semântica de um ou mais blocos de cabeçalho. Cada módulo tem por finalidade oferecer um ou 
mais recursos e precisa declarar os recursos que ele implementa. 

O objetivo por trás dos módulos SOAP é poder escrever um protocolo com um conjunto de recursos 
simplesmente incluindo cada uma das especificações de módulo correspondentes. Se o seu protocolo 
precisar ter uma semântica de no máximo uma vez e autenticação, inclua os módulos correspondentes 
na sua especificação. Isso representa uma nova abordagem para modularizar serviços de protocolo, uma 
alternativa às camadas de protocolo que vimos neste livro. Isso é semelhante a “achatar” uma série de 
camadas de protocolo em um único protocolo, mas de uma forma estruturada. Ainda não sabemos ao 
certo como os recursos e módulos do SOAP introduzidos na versão 1.2 do SOAP funcionarão na prática. 
A principal deficiência desse esquema é que os módulos podem interferir uns com os outros. Uma 
especificação de módulo precisa especificar quaisquer interações conhecidas com outros módulos SOAP 
mas certamente isso não é muito eficiente para aliviar o problema. Entretanto, um conjunto básico de 
recursos e módulos, que ofereça as propriedades mais importantes, pode ser pequeno o suficiente para 
ser bem conhecido e entendido. 


Padronizando protocolos de Web Services 

Como dissemos, WSDL e SOAP não são protocolos; eles são padrões para especificar protocolos. Para que 
empresas diferentes implementem Web Services que interoperem uns com os outros, não basta entrar 
em acordo sobre usar WSDL ou SOAP para definir seus protocolos; elas precisam entrar em acordo sobre 
-ou seja, padronizar —- protocolos específicos. Por exemplo, você poderia imaginar que os revendedores 
on-line e as transportadoras queiram padronizar um protocolo pelo qual elas troquem informações, 
baseado no exemplo simples de rastreamento de pacotes no início desta seção. Essa padronização é 
essencial para o suporte à ferramenta, bem como para a interoperabilidade. Mesmo assim, diferentes 
aplicações de rede nessa arquitetura necessariamente precisam diferir pelo menos nos formatos de 
mensagem e nas operações que elas utilizam. 

Essa tensão entre padronização e personalização é tratada estabelecendo padrões parciais, chamados 
de perfis. Um perfil é um conjunto de diretrizes que estreitam ou restringem escolhas disponíveis na 
WSDL, no SOAP e em outros padrões que podem ser referenciados na definição de um protocolo. Eles 
podem, ao mesmo tempo, resolver ambiguidades ou lacunas nesses protocolos. Na prática, um perfil 
normalmente formaliza um padrão de fato emergente. 

O perfil mais amplo e mais adotado é conhecido como Perfil Básico WS-I (WS-I Basic Profile). Ele foi 
proposto pela Web Services Interoperability Organization (WS-I), um consórcio do setor, enquanto WSDL 
e SOAP são especificados pelo World Wide Web Consortium (W3C). O Perfil Básico resolve algumas das 
escolhas mais básicas enfrentadas na definição de um Web Service. Particularmente, é preciso que a 
WSDL seja vinculada exclusivamente ao SOAP e que o SOAP seja vinculado exclusivamente a HTTP e use 
o método POST do HTTP Ele também especifica quais versões da WSDL e do SOAP devem ser usadas. 

O Perfil de Segurança Básico WS-I (WS-I Basic Security Profile) acrescenta restrições de segurança ao 
Perfil Básico, especificando como a camada SSL/TLS (Seção 8.4.3) deve ser usada e exigindo conformi- 
dade com a especificação WS-Security (Segurança de Web Services). AWS-Security especifica como usar 
diversas técnicas existentes, como certificados de chave pública X.509 (Seção 8.21) e Kerberos (Seção 
8.3.3) para fornecer recursos de segurança nos protocolos SOAP. 

AWS-Security é apenas a primeira de um conjunto crescente de padrões no nível SOAP estabelecidos 
pelo consórcio de indústrias denominado OASIS (Organization for the Advancement of Structured 
Information Standards, ou Organização para o Avanço de Padrões de Informação Estruturada). Os pa- 
drões conhecidos coletivamente como WS-* incluem WS-Reliability (Confiabilidade de Web Services), 
WS-Reliable-Messaging (Mensagens Confiáveis de Web Services), WS-Coordination (Coordenação de 
Web Services) e WS-AtomicTransaction (Transações Atômicas de Web Services). 


Um protocolo de aplicação genérico (REST) 
A arquitetura de Web Services WSDL/SOAP é baseada na suposição de que a melhor maneira de integrar 
aplicações usando redes é por meio de protocolos que são personalizados para cada aplicação. Essa 
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arquitetura é projetada para tornar prática a especificação e a implementação de todos esses protocolos. 
Em comparação, a arquitetura de Web Services REST é baseada na suposição de que a melhor maneira 
de integrar aplicações usando redes é reaplicando o modelo por trás da arquitetura da World Wide Web 
(Seção 9.1.2). Esse modelo, articulado pelo arquiteto da Web chamado Roy Fielding, é conhecido como 
Transferência de Estado Representacional (REST — REpresentational State Transfer). Não há necessidade 
de uma nova arquitetura REST para Web Services — a arquitetura Web existente é suficiente, embora 
algumas extensões provavelmente sejam necessárias. Na arquitetura Web, Web Services individuais 
são considerados como recursos identificados por URIs e acessados via HTTP — um único protocolo de 
aplicação genérico com um único esquema de endereçamento genérico. 

Enquanto WSDL tem operações definidas pelo usuário, REST usa o pequeno conjunto de métodos 
HTTP disponíveis, como GET e POST (ver Tabela 9.1). Assim, como esses métodos simples podem 
oferecer uma interface com um Web Service complexo? Empregando o modelo REST, em que a com- 
plexidade é deslocada do protocolo para a carga útil. A carga útil é uma representação do estado abstrato 
de um recurso. Por exemplo, um GET poderia retornar uma representação do estado atual do recurso, 
e um POST poderia enviar uma representação de um estado desejado do recurso. 

A representação de um estado de recurso é abstrata; ela não precisa se parecer com a forma como o 
recurso é realmente implementado por uma instância em particular do Web Service. Não é necessário 
transmitir um estado de recurso completo em cada mensagem. O tamanho das mensagens pode ser 
reduzido transmitindo apenas as partes de um estado que são de interesse (por exemplo, apenas as partes 
que estão sendo modificadas). E, como os Web Services compartilham um único protocolo e espaço 
de endereços com outros recursos da Web, partes dos estados podem ser passadas por referência — por 
URI - mesmo quando estes estados são outros Web Services. 

Essa abordagem é mais bem resumida como um estilo de passagem de parâmetros orientado a dados 
ou orientado a documentos, ao contrário de um estilo procedural. A definição de um protocolo de 
aplicação nessa arquitetura consiste em definir a estrutura de documento (ou seja, a representação do 
estado). O XML e a Notação de Objetos JavaScript (JSON -JavaScript Object Notation), mais leve, são as 
linguagens de apresentação mais usadas (Seção 7.1) para esse estado. A interoperabilidade depende do 
acordo, entre um Web Service e seu cliente, sobre a representação do estado. Naturalmente, o mesmo 
acontece na arquitetura SOAP; um Web Service e seu cliente precisam entrar em acordo sobre o formato 
da carga útil. A diferença é que, na arquitetura SOAP a interoperabilidade também depende de um 
acordo sobre o protocolo; na arquitetura REST, o protocolo é sempre HTTP de modo que esta fonte de 
problemas de interoperabilidade é eliminada. 

Um dos recursos atrativos do REST é que ele aproveita a infraestrutura que foi implantada para dar 
suporte à Web. Por exemplo, os proxies Web podem impor mecanismos de segurança ou fazer o cache de 
informações. As redes de distribuição de conteúdo (CDNs — Content Distribution Networks) existentes 
podem ser usadas para dar suporte a aplicações com REST. 

Ao contrário do WSDL/SOABP a Web teve tempo para os seus padrões se estabilizarem e para demons- 
trar que ela é bastante escalável. Ela também vem com alguma segurança na forma do Secure Socket 
Layer (SSL)/Transport Layer Security (TLS). A Web e REST também podem ter uma vantagem em sua 
capacidade de evoluir. Embora os arcabouços WSDL e SOAP sejam altamente flexíveis com relação 
a quais novos recursos e vínculos podem entrar na definição de um protocolo, essa flexibilidade é 
irrelevante quando o protocolo é definido. Os protocolos padronizados, como HTTP são projetados 
prevendo a extensão de uma maneira compatível. A extensibilidade do HTTP em si toma a forma de 
cabeçalhos, novos métodos e novos tipos de conteúdo. Os projetistas de protocolo usando WSDL/SOAP 
precisam projetar essa extensibilidade em cada um de seus protocolos personalizados. Naturalmente, 
os projetistas de representações de estado em uma arquitetura REST também precisam fazer projetos 
visando a capacidade de evoluir. 

Uma área na qual WSDL/SOAP pode ter uma vantagem é na adaptação ou empacotamento de 
aplicações previamente escritas, “legadas”, para que elas fiquem em conformidade com Web Services. 
Esse é um ponto importante, pois a maioria dos Web Services será baseada em aplicações legadas pelo 
menos no futuro próximo. Essas aplicações normalmente possuem uma interface procedural que é 
mapeada mais facilmente em operações da WSDL do que em estados REST. A competição entre REST 
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e WSDL/SOAP pode muito bem depender da facilidade ou dificuldade de idealizar interfaces em estilo 
REST para Web Services individuais. Podemos descobrir que alguns Web Services são mais bem servidos 
pelo WSDL/SOAP e outros pelo REST. 

O varejista on-line Amazon.com, a propósito, foi um dos primeiros (em 2002) a adotar Web Services. 
É interessante que a Amazon tornou seus sistemas publicamente acessíveis por meio de arquiteturas 
de Web Services e, de acordo com alguns relatos, uma maioria substancial dos desenvolvedores utiliza 
a interface REST. Naturalmente, essa é apenas uma fonte de dados e pode muito bem refletir fatores 
específicos à Amazon. 

& 
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Assim como as aplicações tradicionais da seção anterior, as aplicações multimídia, como aplicações 
de telefonia e videoconferência, precisam de protocolos da camada de aplicação. Grande parte da ex- 
periência inicial no projeto de protocolos para aplicações multimídia veio das “ferramentas MBone” 
— aplicações como vat e vic, que foram desenvolvidas para uso no MBone, usando o multicast IP para 
habilitar conferências entre múltiplas partes. (Veja mais sobre redes overlay, incluindo o Mbone, na 
próxima seção.) Inicialmente, cada aplicação implementava seu próprio protocolo (ou protocolos), 
mas logo ficou aparente que muitas aplicações multimídia possuem requisitos em comum. Isso por 
fim levou ao desenvolvimento de uma série de protocolos de propósito geral para uso em aplicações 
multimídia. 

Já vimos uma série de protocolos que as aplicações multimídia utilizam. O protocolo de transporte 
em tempo real (RTP — Real-time Transport Protocol, descrito na Seção 5.4), oferece muitas das funções 
que são comuns às aplicações multimídia, como transportar informações de tempo e identificar os 
esquemas de codificação e tipos de mídia de uma aplicação. 

O protocolo de reserva de recursos (RSVP — Resource Reservation Protocol; ver Seção 6.5.2) pode ser 
usado para solicitar a alocação de recursos na rede, de modo que a qualidade de serviço (QoS) desejada 
possa ser fornecida a uma aplicação. Veremos como a alocação de recursos interage com outros aspectos 
das aplicações multimídia na Seção 9.2.2. 

Além desses protocolos para transporte de multimídia e alocação de recursos, muitas aplicações 
multimídia também precisam de um protocolo de sinalização ou controle de sessão. Por exemplo, 
suponha que quiséssemos ser capazes de fazer ligações telefônicas através da Internet (Voz sobre IP ou 
VoIP). Precisaríamos de algum mecanismo para avisar ao destinatário desejado que queremos falar com 
ele, por exemplo, enviando uma mensagem a algum dispositivo de multimídia que faria tocar um som 
de campainha. Também gostaríamos de dar suporte a recursos como encaminhamento de chamada, 
colocar a chamada em espera e assim por diante. O protocolo de iniciação de sessão (SIP — Session 
Initiation Protocol) e o H.323 são exemplos de protocolos que resolvem as questões de controle de sessão; 
vamos começar nossa discussão sobre aplicações multimídia examinando esses protocolos. 


9.2.1 Controle de sessão e controle de chamada (SDP SIP H.323) 


Para entender algumas das questões do controle de sessão, considere o problema a seguir. Suponha que 
você queira fazer uma videoconferência em certo horário e torná-la disponível a uma grande quantidade 
de participantes. Talvez você tenha decidido codificar o fluxo de vídeo usando o padrão MPEG-2, usar 
o endereço IP de multicast 224.1.1.1 para a transmissão dos dados e enviá-los usando RTP pela porta 
UDP número 4000. Como você disponibilizaria toda essa informação aos participantes alvo? Um modo 
seria colocar toda essa informação em uma mensagem de correio eletrônico e enviá-la, mas o ideal é 
que haja um formato e um protocolo padrão para disseminar esse tipo de informação. A IETF definiu 
protocolos exatamente para essa finalidade. Os protocolos que foram definidos incluem: 


e SDP (Session Description Protocol — protocolo de descrição de sessão). 

SAP (Session Announcement Protocol — protocolo de anúncio de sessão). 

SIP (Session Initiation Protocol — protocolo de iniciação de sessão). 

SCCP (Simple Conference Control Protocol- protocolo simples de controle de conferência). 
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Você poderia pensar que são muitos protocolos para uma tarefa aparentemente simples, mas existem 
muitos aspectos do problema e várias situações diferentes em que esse problema precisa ser enfrentado. 
Por exemplo, há uma diferença entre anunciar o fato de que uma sessão de conferência estará disponível 
no MBone (o que seria feito usando SDP e SAP) e tentar fazer uma chamada telefônica pela Internet para 
um certo usuário em um horário específico (o que poderia ser feito usando SDP e SIP). No primeiro caso, 
você poderia considerar seu trabalho como estando pronto quando tivesse enviado toda a informação 
de sessão em um formato padrão para um endereço de multicast bem conhecido. No segundo, você 
precisaria localizar um ou mais usuários, levar uma mensagem para eles anunciando seu desejo de falar 
(semelhante a ligar para o telefone deles), e talvez negociar uma codificação de áudio adequada entre 
todas as partes. Veremos primeiro o SDP que é comum a muitas aplicações, depois o SIP que é bastante 
utilizado para diversas aplicações interativas, como telefonia na Internet. 


Session Description Protocol (SDP) 

O protocolo de descrição de sessão (SDP — Session Description Protocol) é um protocolo um tanto geral, 
que pode ser usado em diversas situações e normalmente é usado em conjunto com um ou mais outros 
protocolos (por exemplo, SIP). Ele transporta as seguintes informações: 


e Onomeea finalidade da sessão. 

e Horas de início e fim para a sessão. 

e Os tipos de mídia (por exemplo, áudio e vídeo) que compõem a sessão. 

e Informações detalhadas necessárias para receber a sessão (por exemplo, o endereço de multicast 
ao qual os dados serão enviados, o protocolo de transporte a ser usado, os números de porta 
e os esquemas de codificação). 


O SDP fornece essa informação formatada em ASCII usando uma sequência de linhas de texto, 
cada uma na forma “< tipo > = < valor >”. Um exemplo de uma mensagem SDP ilustrará os pontos 
principais. 


v=0 

o=larry 2890844526 2890842807 IN IP4 128.112.136.10 
s=Redes 101 

i=Uma aula sobre redes de computadores 
u=http://www.cs.princeton.edu/ 
e=larryDcs.princeton.edu 

c=IN IP4 224.2.17.12/127 

t=2873397496 2873404696 

m=audio 49170 RTP/AVP 0 

ma=video 51372 RTP/AVP 31 
m=application 32416 udp wb 


Observe que o SDP assim como o HTML, é muito fácil de ser lido por um humano, mas possui re- 
gras de formatação estritas, que possibilitam a interpretação dos dados pelas máquinas sem que haja 
ambiguidade. Por exemplo, a especificação do SDP define todos os tipos de informação possíveis que 
podem aparecer, a ordem em que eles precisam aparecer e o formato e palavras reservadas para cada 
tipo definido. 

A primeira coisa a observar é que cada tipo de informação é identificado por um único caractere. Por 
exemplo, a linha v= 0 nos diz que a “versão” possui o valor zero; ou seja, essa mensagem é formatada de 
acordo com a versão zero do SDP A linha seguinte indica a “origem” da sessão, que contém informações 
suficientes para identificar a sessão exclusivamente. larry é um nome de usuário do criador da sessão, e 
128.112.136.10 é o endereço IP de seu computador. O número após larry é um identificador de sessão, 
que é escolhido para ser exclusivo a essa máquina. Este é seguido por um número de “versão” para o 
anúncio do SDP; se a informação de sessão fosse atualizada por uma mensagem mais tarde, o número 
da versão seria incrementado. 

As três linhas seguintes (s, i e u) fornecem o nome da sessão, uma descrição da sessão e um identifi- 
cador de recurso uniforme (URI, conforme descrito na Seção 9.1.2) — todos oferecem informações que 
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seriam úteis a um usuário na decisão de participar ou não desta sessão. Essas informações poderiam ser 
exibidas na interface com o usuário de uma ferramenta de diretório de sessão, que mostre os eventos 
atuais e os que estão por vir, que foram anunciados usando SDP A linha seguinte (e=...) contém um 
endereço de e-mail de uma pessoa de contato relativa à sessão. A Figura 9.7 mostra uma captura de tela 
de uma ferramenta de diretório de sessão chamada sdr, junto com as descrições de várias sessões que 
foram anunciadas no momento em que foi feita a captura da imagem. 

Em seguida, chegamos aos detalhes técnicos que permitiriam que um programa de aplicação 
participasse da sessão. A linha que começa com c=... fornece o endereço IP de multicast ao qual os 
dados para essa sessão serão enviados; um usuário precisaria ingressar nesse grupo de multicast para 
receber a sessão. Em seguida, vemos os horários de início e fim da sessão (codificados como inteiros, de 
acordo com o NTP — Network Time Protocol). Finalmente, chegamos à informação sobre a mídia dessa 
sessão. Essa sessão possui três tipos de mídia disponíveis — áudio, vídeo e uma aplicação de quadro 
branco compartilhado, conhecida como “wb”. Para cada tipo de mídia, existe uma linha de informações 
formatada da seguinte forma: 


m=<mídia> <porta> <transporte> <formato> 


Os tipos de mídia são autoexplicativos, e os números de porta em cada caso são portas UDP Quando 
examinamos o campo “transporte”, podemos ver que a aplicação wb executa diretamente em cima do UDB 
enquanto o áudio e o vídeo são transportados usando “RTP /AVP”. Isso significa que eles são executados em 
cima de RTP e utilizam o perfil de aplicação (conforme definido na Seção 5.4) conhecido como AVP. Esse 
perfil de aplicação define uma série de esquemas de codificação diferentes para áudio e vídeo; podemos 
ver, neste caso, que o áudio está usando a codificação 0 (que é uma codificação usando uma taxa de amos- 
tragem de 8 KHz e 8 bits por amostra) e o vídeo está usando a codificação 31, que representa o esquema 
de codificação H.261. Esses “números mágicos” para os esquemas de codificação são definidos na REC 
que define o perfil AVP; também é possível descrever esquemas de codificação não padrão no SDP 

Finalmente, vemos uma descrição do tipo de mídia “wb”. Toda a informação de codificação para 
esses dados é específica à aplicação wb, e por isso é suficiente apenas fornecer o nome da aplicação no 
campo de “formato”. Isso é semelhante a colocar applicationAwb em uma mensagem MIME. 

Agora que sabemos como descrever sessões, podemos examinar como elas podem ser iniciadas. Uma 
maneira em que o SDP é usado é para anunciar conferências multimídia, enviando mensagens SDP a 
um endereço de multicast bem conhecido. A ferramenta de diretório de sessão mostrada na Figura 9.7 
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FIGURA 9.7 Uma ferramenta de diretório de sessão mostra informações extraídas das mensagens SDP. 
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funcionaria entrando nesse grupo de multicast e exibindo informações que ela obtém das mensagens 
SDP recebidas. O SDP também é usado na entrega de vídeo de entretenimento do IP (normalmente 
chamado IPTV) para fornecer informações sobre o conteúdo de vídeo em cada canal de TV. 

O SDP também desempenha um papel importante em conjunto com o Session Initiation Protocol 
(SIP). Com a importância cada vez maior da “voz sobre IP” (VOIP — Voice Over IP), ou seja, o suporte 
a aplicações do tipo telefonia sobre redes IP e videoconferência baseada em IP o SIP agora é um dos 
membros mais importantes do conjunto de protocolos da Internet. 


SIP 

O SIP é um protocolo da camada de aplicação que possui uma certa semelhança com o HTTP sendo 
baseado em um modelo de solicitação /resposta semelhante. Contudo, ele é projetado visando tipos 
de aplicações um tanto diferentes, e desse modo oferece muitos mecanismos diferentes do HTTP Os 
mecanismos oferecidos pelo SIP podem ser agrupadas em cinco categorias: 


e Localização do usuário: determinar o dispositivo correto com o qual se comunica para alcançar 
um usuário específico. 
e Disponibilidade do usuário: determinar se o usuário deseja ou pode tomar parte de uma sessão 
de comunicação em particular. 
e Recursos do usuário: determinar itens como a escolha de mídia e esquema de codificação a utilizar. 
e Configuração da sessão: estabelecer parâmetros de sessão como números de porta a serem usados 
pelas partes comunicantes. 
e Gerenciamento de sessão: uma gama de funções incluindo transferir sessões (por exemplo, 
para implementar o “encaminhamento de chamada”) e modificar parâmetros da sessão. 


A maioria dessas funções é muito fácil de entender, mas a questão da localização merece um pouco 
mais de explicação. Uma diferença importante entre o SIP e, digamos, o HTTP é que o SIP é usado 
principalmente para a comunicação entre humanos. Assim, é importante poder localizar usuários in- 
dividuais, e não apenas máquinas. E, ao contrário do correio eletrônico, não é suficiente apenas localizar 
um servidor que o usuário verificará em alguma data posterior e jogar a mensagem lá — precisamos 
saber onde o usuário está agora, se quisermos nos comunicar com ele em tempo real. Isso pode se 
tornar mais complicado pelo fato de que um usuário poderia decidir se comunicar usando diversos 
dispositivos diferentes, por exemplo, usando seu computador de mesa quando estiver no escritório e 
usando um dispositivo portátil quando estiver viajando. Vários dispositivos poderiam estar ativos ao 
mesmo tempo e poderiam ter recursos muito diferentes (por exemplo, um pager alfanumérico e um 
“videofone” executado em um PC). O ideal é que os outros usuários possam localizar e se comunicar 
com o dispositivo apropriado a qualquer momento. Além disso, o usuário precisa ser capaz de ter con- 
trole sobre quando, onde e de quem ele recebe ligações. 

Para permitir que um usuário exercite o nível de controle apropriado sobre suas ligações, o SIP 
introduz a noção de um proxy. Um proxy SIP pode ser imaginado como um ponto de contato para um 
usuário, ao qual as solicitações iniciais de comunicação com este usuário são enviadas. Proxies também 
realizam funções em favor dos usuários que fazem a chamada. Podemos ver como os proxies funcionam 
melhor por meio de um exemplo. 

Considere os dois usuários da Figura 9.8. A primeira coisa a observar é que cada usuário possui um 
nome no formato usuário @ domínio, muito semelhante a um endereço de correio eletrônico. Quando 
o usuário Bruce deseja iniciar uma sessão com Larry, ele envia sua mensagem SIP inicial ao proxy local 
de seu domínio, cisco.com. Entre outras coisas, essa mensagem inicial contém um URI SIP — essa é uma 
forma de identificador de recurso uniforme que se parece com isto: 


SIP:larry(Dprinceton.edu 


Um URI SIP fornece identificação completa de um usuário, mas (ao contrário de um URL) não 
fornece sua localização, pois isso pode mudar com o tempo. Veremos em breve como a localização de 
um usuário pode ser determinada. 
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proxy 


proxy cisco.com princeton.edu 


bsd-pc.cisco.com llp-ph.cs.princeton.edu 


brucewcisco.com larryoprinceton.edu 


FIGURA 9.8 Estabelecendo a comunicação através de proxies SIP. 


Ao receber a mensagem inicial de Bruce, o proxy cisco.com examina o URI SIP e deduz que essa 
mensagem precisa ser enviada para o proxy princeton.edu. Por enquanto, vamos considerar que o proxy 
princeton.edu tem acesso a algum banco de dados que lhe permite obter um mapeamento do nome 
larry O princeton.edu ao endereço IP de um ou mais dispositivos em que Larry atualmente deseja receber 
mensagens. O proxy pode, portanto, encaminhar a mensagem para o(s) dispositivo(s) escolhido(s) de 
Larry. O envio da mensagem a mais de um dispositivo é chamado de bifurcação, e pode ser feito em 
paralelo ou em série (por exemplo, envie-a ao seu telefone celular se ele não responder ao telefone 
em sua mesa). 

A mensagem inicial de Bruce para Larry provavelmente será uma mensagem de convite SIP que se 
parece com: 


INVITE sip:larryeprinceton.edu SIP/2.0 

Via: SIP/2.0/UDP bsd-pc.cisco.com;branch=z9hG4bK433yLe4 
To: Larry <sip:larryQprinceton.edu> 

From: Bruce <sip:brucefcisco.com>; Lag=55123 

Call-ID: xy/45jj210re3ebsd -pc.cisco.com 


CSeq: 271828 INVITE 

Contact: <sip:bruceebsd-pc.cisco.com> 
Content-Type: application/sdp 
Content-Length: 142 


A primeira linha identifica o tipo de função a ser realizada (invite); o recurso no qual ela será realizada, 
ou seja, a parte chamada (sip:larry O princeton.edu) e a versão do protocolo (2.0). As próximas linhas de 
cabeçalho parecem familiares devido à sua semelhança com as linhas de cabeçalho em uma mensagem 
de correio eletrônico. O SIP define uma quantidade maior de campos de cabeçalho, mas vamos descrever 
apenas alguns deles aqui. Observe que o cabeçalho Via: neste exemplo identifica o dispositivo a partir do 
qual essa mensagem foi originada. Os campos Content-Type: e Content-Length: descrevem o conteúdo 
da mensagem após o cabeçalho, assim como em uma mensagem de correio eletrônico codificada com 
MIME. Neste caso, o conteúdo é uma mensagem SDP Essa mensagem descreveria coisas como o tipo de 
mídia (áudio, vídeo etc.) que Bruce gostaria de trocar com Larry e outras propriedades da sessão, como 
os tipos de CODEC que ele admite. Observe que o campo Content-Type: no SIP oferece a capacidade de 
usar qualquer protocolo para essa finalidade, embora o SDP seja o mais comum. 

Retornando ao exemplo, quando a mensagem invite chega no proxy cisco.com, o proxy não apenas 
encaminha a mensagem para princeton.edu, mas também responde ao emissor do invite. Assim como 
no HTTP todas as respostas possuem um código de resposta, e a organização dos códigos é semelhante 
à que é usada para o HTTP como mostra a Tabela 9.2. Na Figura 9.9, podemos ver uma sequência de 
mensagens e respostas SIP 

A primeira mensagem de resposta nessa figura é a resposta provisória 100 trying (“tentando”), que 
indica que a mensagem foi recebida sem erros pelo proxy de quem fez a chamada. Quando o invite é 
entregue ao telefone de Larry, ele alerta Larry e responde com uma mensagem 180 ringing (“tocando”), 
A chegada dessa mensagem no computador de Bruce é um sinal de que ela pode gerar um “som de 
chamada”. Supondo que Larry queira e possa se comunicar com Bruce, ele poderia apanhar o telefone, 
causando o envio da mensagem 200 OK. O computador de Bruce responde com um ACK, e nesse 
ponto a mídia (por exemplo, um fluxo de áudio encapsulado no RTP) pode começar a fluir entre as 
duas partes. Observe que, neste ponto, as partes conhecem o endereço uma da outra, de modo que o 
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FIGURA 9.9 Fluxo de mensagens para uma sessão SIP básica. 


ACK pode ser enviado diretamente, evitando os proxies. Os proxies agora não estão mais envolvidos na 
chamada. Observe que a mídia, portanto, normalmente toma um caminho através da rede diferente 
daquele tomado pelas mensagens de sinalização originais. Além disso, mesmo que um ou ambos os 
proxies falhassem nesse ponto, a chamada poderia prosseguir normalmente. Finalmente, quando uma 
parte deseja encerrar a sessão, ela envia uma mensagem BYE, o que evoca uma resposta 200 OK sob 
circunstâncias normais. 

Existem alguns detalhes que apenas mencionamos brevemente. Um deles é a negociação das carac- 
terísticas da sessão. Talvez Bruce preferisse se comunicar usando áudio e vídeo, mas o telefone de Larry 
só aceite áudio. Assim, o telefone de Larry enviaria uma mensagem SDP em seu 200 OK, descrevendo 
as propriedades da sessão que são aceitáveis por Larry e pelo dispositivo, considerando as opções que 
foram propostas no invite de Bruce. Desse modo, as partes entram em acordo sobre os parâmetros de 
sessão mutuamente aceitáveis antes do início do fluxo de mídia. 

A outra grande questão que apenas mencionamos brevemente é a de localizar o dispositivo correto 
de Larry. Primeiro, o computador de Bruce teve de enviar seu invite ao proxy cisco.com. Esta poderia 
ter sido uma informação configurada no computador, ou então poderia ter sido descoberta por DHCP. 
Depois, o proxy cisco.com teve de encontrar o proxy princeton.edu. Isso poderia ser feito usando um 
tipo especial de pesquisa de DNS, que retornaria o endereço IP do proxy SIP para o domínio princeton. 
edu. (Discutiremos como o DNS pode fazer isso na Seção 9.3.1.) Finalmente, o proxy princeton.edu teve 
de encontrar um dispositivo no qual Larry poderia ser contatado. Normalmente, um servidor proxy tem 
acesso ao banco de dados de locais, que pode ser preenchido de várias maneiras. A configuração manual 
é uma opção, porém uma opção mais flexível é usar as capacidades de registro do SIP 

Um usuário pode registrar-se junto a um serviço local enviando uma mensagem register do SIP ao 
“registrador” para o seu domínio. Essa mensagem cria um vínculo entre um “endereço de registro” e 
um “endereço de contato”. Um endereço de registro provavelmente é um URI SIP, que é o endereço 
bem conhecido para o usuário (por exemplo, sip:larry O princeton.edu), e o endereço de contato 
será o endereço no qual o usuário pode ser encontrado atualmente (por exemplo, sip:larry O Ilp-ph. 
cs.princeton.edu). É exatamente esse o vínculo que foi necessário para o proxy princeton.edu em 
nosso exemplo. 

Observe que um usuário pode se registrar em vários locais e que vários usuários podem se registrar 
em um único dispositivo. Por exemplo, você pode imaginar um grupo de pessoas entrando em uma 
sala de conferências equipada com um telefone IP e todas elas registrando-se nele para que possam 
receber chamadas nesse telefone. 
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O SIP é um protocolo bastante rico e flexível, que é capaz de dar suporte a uma grande variedade de 
cenários complexos de ligações telefônicas, além de aplicações que tenham pouco ou nada a ver com 
telefonia. Por exemplo, o SIP tem suporte a operações que permitem que uma chamada seja roteada 
para um servidor de músicas ou para um servidor de correio de voz. Também é fácil ver como ele poderia 
ser usado para aplicações como mensagem instantânea; a padronização de extensões do SIP para essas 
finalidades estava em andamento quando este livro foi escrito. 


H.323 

A União Internacional de Telecomunicação (ITU — International Telecommunication Union) também 
tem estado ativa na área de controle de chamada, o que não é surpresa dada sua relevância para a 
telefonia, o campo de atuação tradicional desse órgão. Felizmente, tem havido bastante coordenação 
entre IETF e ITU nesse assunto, de modo que os diversos protocolos são relativamente interoperáveis. 
A principal recomendação da ITU para comunicação multimídia por redes de pacotes é conhecida 
como H.323, que reúne muitas outras recomendações, incluindo o H.225 para controle de chamada. 
O conjunto completo de recomendações incluídas no H.323 chega a muitas centenas de páginas, e 
o protocolo é conhecido por sua complexidade, de modo que apresentamos aqui apenas um rápido 
esboço. 

O H.323 é popular como um protocolo para telefonia na Internet, e por isso consideramos essa 
aplicação aqui. Um dispositivo que origina ou termina chamadas é conhecido como terminal H.323; 
ele poderia ser uma estação de trabalho executando uma aplicação de telefonia via Internet ou então 
um “aparelho” projetado especialmente — um dispositivo semelhante a um telefone, com software de 
rede e porta Ethernet, por exemplo. Terminais H.323 podem se comunicar entre si diretamente, mas 
as chamadas normalmente são mediadas por um dispositivo conhecido como gatekeeper (guardião). 
Os gatekeepers realizam diversas funções, como traduzir entre os diversos formatos de endereço 
usados para ligações telefônicas e controlar como muitas chamadas podem ser feitas em determinado 
momento, para limitar a largura de banda usada pelas aplicações H.323. O H.323 também inclui 
o conceito de um gateway, que conecta a rede H.323 a outros tipos de redes. O uso mais comum de 
um gateway é conectar uma rede H.323 à rede telefônica pública (PSTN - Public Switched Telephone 
Network), conforme ilustramos na Figura 9.10. Isso permite que um usuário executando uma aplicação 
H.323 em um computador fale com uma pessoa usando um telefone convencional na rede telefônica 
pública. Uma função útil realizada pelo gatekeeper é ajudar um terminal a localizar um gateway, talvez 
escolhendo entre várias opções, para encontrar um que esteja relativamente perto do destino final 
da chamada. Isso certamente é útil em um mundo onde os telefones convencionais são muito mais 
numerosos que os telefones baseados em PC. Quando um terminal H.323 faz uma chamada para um 
terminal que é um telefone convencional, o gateway torna-se o terminal de fato para a chamada H.323 
e é responsável por realizar a tradução apropriada da informação de sinalização e do fluxo de mídia que 
precisa ser transportado pela rede telefônica. 
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FIGURA 9.10 Dispositivos em uma rede H.323. 
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Uma parte importante do H.323 é o protocolo H.245, que é usado para negociar as propriedades da 
chamada, de modo semelhante ao uso do SDP descrito anteriormente. Uma mensagem H.245 poderia 
listar uma série de padrões de codec de áudio diferentes que ele possa admitir, e a extremidade final da 
chamada poderia responder com uma lista de seus próprios codecs suportados, e as duas extremidades 
poderiam escolher um padrão de codificação com o qual elas possam conviver. O H.245 também pode 
ser usado para sinalizar os números de porta UDP que serão usados pelo RTP e pelo RTCP (Real-Time 
Control Protocol) para o fluxo de mídia (ou fluxos, pois uma chamada poderia incluir áudio e vídeo, por 
exemplo) nessa chamada. Quando isso é feito, a chamada pode prosseguir, com o RTP sendo usado para 
transportar os fluxos de mídia e o RTCP transportando as informações de controle relevantes. 


9.2.2 Alocação de recursos para aplicações multimídia 


Como já vimos, os protocolos de controle de sessão, como SIP e H.323, podem ser usados para iniciar 
e controlar a comunicação em aplicações multimídia, enquanto o RTP oferece funções em nível de 
transporte para os fluxos de dados das aplicações. Uma peça final do quebra-cabeças para fazer as 
aplicações multimídia funcionarem é garantir que os recursos adequados sejam alocados dentro da 
rede para garantir que as necessidades de qualidade de serviço da aplicação sejam atendidas. Apresen- 
tamos diversos métodos para alocação de recursos no Capítulo 6. A motivação para desenvolver essas 
tecnologias foi em grande parte para dar suporte a aplicações multimídia. Então, como as aplicações 
tiram proveito das capacidades básicas de alocação de recursos da rede? 

Vale a pena observar que muitas aplicações multimídia são executadas com sucesso por redes de “me- 
lhor esforço”, como a Internet pública. A grande quantidade de serviços VoIP comerciais (como o Skype) 
comprovam o fato de que você só precisa se preocupar com a alocação de recursos quando os recursos 
não são abundantes — e em muitas partes da Internet de hoje, a abundância de recursos é a norma. 

Um protocolo como o RTCP (Seção 5.4) pode ajudar as aplicações nas redes de melhor esforço, dando 
à aplicação informações detalhadas sobre a qualidade de serviço que está sendo entregue pela rede. 
Lembre-se que o RTCP transporta informações sobre a taxa de perdas e as características de atraso entre 
os participantes de uma aplicação multimídia. Uma aplicação pode usar essa informação para mudar seu 
esquema de codificação - mudando para um codec com taxa de bits mais baixa, por exemplo, quando 
a largura de banda é escassa. Observe que, embora possa ser tentador mudar para um codec que envia 
informações adicionais e redundantes quando as taxas de perda são altas, isso é desaconselhado; isso 
é semelhante a aumentar o tamanho da janela do TCP na presença de perda, exatamente o oposto do 
que é exigido para evitar um colapso devido ao congestionamento. 

Conforme discutimos na Seção 6.5.3, o esquema de Serviços Diferenciados (DiffServ) pode ser usado 
para oferecer uma alocação de recursos bastante básica e escalável às aplicações. Uma aplicação mul- 
timídia pode definir o ponto de código dos serviços diferenciados (DSCP - Differentiated Services Code 
Point) no cabeçalho IP dos pacotes que ela gera em um esforço para garantir que a mídia e os pacotes 
de controle recebam uma qualidade de serviço apropriada. Por exemplo, é comum marcar os pacotes de 
mídia de voz como “EF” (encaminhamento expresso) para fazer com que eles sejam colocados em uma 
fila de baixa latência ou maior prioridade nos roteadores ao longo do caminho, enquanto os pacotes 
de sinalização de chamada (por exemplo, SIP) normalmente são marcados com algum tipo de “AF” 
(encaminhamento garantido) para permitir que eles sejam enfileirados separadamente do tráfego de 
melhor esforço e, assim, reduzam seu risco de perda. 

Naturalmente, só faz sentido marcar os pacotes dentro do host ou do aparelho emissor se os dis- 
positivos de rede como roteadores prestarem atenção ao DSCP Em geral, os roteadores na Internet 
pública ignoram o DSCP oferecendo serviços de melhor esforço a todos os pacotes. Porém, as redes 
empresariais ou corporativas têm a capacidade de usar DiffServ para seu tráfego multimídia interno, e 
frequentemente fazem isso. Além disso, até mesmo usuários residenciais da Internet constantemente 
melhoram a qualidade do VoIP ou outras aplicações de multimídia simplesmente usando DiffServ na 
direção de saída de suas conexões com a Internet, conforme ilustramos na Figura 9.11. Isso é eficaz 
devido à assimetria de muitas conexões de banda larga com a Internet: se o enlace de saída for muito 
mais lento (ou seja, mais restrito em termos de recursos) do que o de entrada, então a alocação de 
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FIGURA 9.11 Serviços Diferenciados aplicados a uma aplicação de VolP. O enfileiramento DiffServ é aplicado somente no enlace na direção 
do roteador do cliente ao ISP. 


recursos usando DiffServ nesse enlace pode ser suficiente para fazer toda a diferença na qualidade para 
aplicações sensíveis a latência e a perdas. 

Embora o DiffServ seja atraente por sua simplicidade, é claro que ele não é capaz de atender às 
necessidades das aplicações sob todas as condições. Por exemplo, suponha que a largura de banda 
no sentido do usuário para o ISP na Figura 9.11 seja apenas de 100 kbps, e o cliente tente fazer duas 
chamadas VoIP cada uma com um codec de 64 kbps. Logicamente, o enlace nesta direção agora está 
mais do que 100% carregado, o que ocasionará grandes atrasos de enfileiramento e pacotes perdidos. 
Por mais que haja um enfileiramento inteligente no roteador do cliente, isso não pode ser corrigido. 

As características de muitas aplicações multimídia são tais que, ao invés de tentar espremer muitas 
chamadas em uma tubulação muito estreita, seria melhor bloquear uma chamada enquanto se permite 
que outra prossiga. Ou seja, é melhor que uma pessoa realize uma conversa com sucesso enquanto 
outra escuta um sinal de ocupado do que ter duas pessoas experimentando uma qualidade de áudio 
inaceitável ao mesmo tempo. Às vezes dizemos que tais aplicações possuem uma curva de utilidade 
íngreme, significando que a utilidade da aplicação cai rapidamente à medida que a qualidade do serviço 
fornecido pela rede é degradada. As aplicações multimídia normalmente possuem essa propriedade, 
enquanto muitas aplicações tradicionais não a têm. O correio eletrônico, por exemplo, continua a 
funcionar muito bem, mesmo que os atrasos possam chegar a horas. 

Aplicações com curvas de utilidade íngremes normalmente são bem adequadas para se utilizar 
alguma forma de controle de admissão. Se você não puder ter certeza de que sempre haverá recursos 
suficientes à disposição para dar suporte à carga oferecida pelas aplicações, então o controle de ad- 
missão fornece um modo de dizer “não” a algumas aplicações enquanto permite que outras recebam 
os recursos de que precisam. 

Vimos um modo de realizar controle de admissão usando o RSVP na Seção 6.5.2, e retornaremos a isso 
em breve, mas as aplicações multimídia que usam protocolos de controle de sessão oferecem algumas 
outras opções de controle de admissão. O ponto principal a ser observado aqui é que os protocolos de 
controle de sessão, como SIP ou H.323, normalmente envolvem algum tipo de troca de mensagem entre 
um terminal e outra entidade (proxy SIP ou gatekeeper H.323) no início de uma chamada ou sessão. Isso 
pode oferecer um meio prático de dizer “não” a uma nova chamada para a qual não existem recursos 
suficientes. 

Como um exemplo, considere a rede na Figura 9.12. Suponha que o enlace remoto da filial até o escri- 
tório central tenha largura de banda suficiente para acomodar três chamadas de VoIP simultaneamente 
usando codecs de 64 kbps. Cada telefone já precisa se comunicar com o proxy SIP ou gatekeeper H.323 
local quando começar a fazer uma chamada, de modo que é muito fácil para um proxy/gatekeeper 
enviar de volta uma mensagem que diz ao telefone IP para tocar um sinal de ocupado se esse enlace já 
estiver totalmente carregado. O proxy ou gatekeeper pode até mesmo lidar com a possibilidade de que 
um telefone IP em particular possa estar fazendo várias chamadas ao mesmo tempo e que diferentes 





Capítulo 9º Aplicações 453 
as 
ELSEVIER 


Proxy ou gatekeeper 


Enlace 


remoto P 
ap Escritório central 





Telefones IP 
na filial 


FIGURA 9.12 Controle de admissão usando o protocolo de controle de sessão. 


velocidades de codec possam ser usadas. Porém, esse esquema só funcionará se nenhum outro dispositi- 
vo puder sobrecarregar o enlace sem primeiro falar com o gatekeeper ou proxy. O enfileiramento DiffServ 
pode ser usado para garantir que, por exemplo, um PC realizando uma transferência de arquivo não 
interfira com as chamadas VoIP Porém, suponha que alguma aplicação VoIP que não fale primeiro com 
o gatekeeper ou proxy seja habilitada no escritório remoto. Essa aplicação, se puder receber seus pacotes 
marcados de modo apropriado e na mesma fila do tráfego VoIP existente, certamente poderá controlar 
o enlace até o ponto de sobrecarga sem intervenção do proxy ou gatekeeper. 

Outro problema com a técnica que descrevemos é que ela depende do gatekeeper ou proxy ter co- 
nhecimento do caminho que cada aplicação usará. Na topologia simples da Figura 9.12, isso não é um 
grande problema, porém, em redes mais complexas, isto pode rapidamente se tornar incontrolável. 
Só precisamos imaginar o caso onde o escritório remoto tem duas conexões diferentes com o mundo 
exterior para ver que estamos pedindo ao proxy ou gatekeeper para entender não apenas SIP ou H.323, 
mas também roteamento, falhas de enlace e condições atuais da rede. Isso pode rapidamente se tornar 
incontrolável. 

Referimo-nos ao tipo de controle de admissão descrito como fora do caminho, no sentido de que o 
dispositivo que toma as decisões de controle de admissão não se localiza no caminho de dados no qual 
os recursos precisam ser alocados. A alternativa óbvia é o controle de admissão no caminho, e o exemplo 
padrão de um protocolo que realiza controle de admissão no caminho, nas redes IP, é o protocolo de 
reserva de recursos (RSVP — Resource Reservation Protocol). Na Seção 6.5.2, vimos como o RSVP pode ser 
usado para garantir que recursos suficientes sejam alocados ao longo de um caminho, e é simples usar o 
RSVP em aplicações como aquelas descritas nesta seção. O único detalhe que ainda precisa ser explicado 
é como o protocolo de controle de admissão interage com o protocolo de controle de sessão. 

A coordenação das ações de um protocolo de controle de admissão (ou reserva de recursos) e de 
um protocolo de controle de sessão não é algo tão complicado, mas exige alguma atenção aos detalhes. 
Como um exemplo, considere uma ligação telefônica simples entre duas partes. Antes que você possa 
fazer uma reserva, precisa saber quanta largura de banda a chamada irá usar, o que significa que você 
precisa saber quais codecs devem ser usados. Isso implica que você precisa realizar algum controle 
de sessão primeiro, para trocar informações sobre os codecs usados pelos dois telefones. Porém, você 
não pode fazer todo o controle de sessão primeiro, pois não gostaria que o telefone tocasse antes que 
a decisão do controle de admissão fosse tomada, caso o controle de admissão falhasse. A Figura 9.13 
ilustra essa situação, onde o SIP é usado para controle de sessão e o RSVP é usado para tomar a decisão 
do controle de admissão (neste caso, com sucesso). 

O principal a observar aqui é a intercalação das tarefas de controle de sessão e alocação de recursos. As 
linhas sólidas representam mensagens SIP e as linhas tracejadas representam mensagens RSVP Observe 
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que as mensagens SIP são transmitidas diretamente de um telefone para outro neste exemplo (ou seja, 
não mostramos quaisquer proxies SIP), enquanto as mensagens RSVP também são processadas pelos 
roteadores intermediários, para verificar se há recursos suficientes para aceitar a chamada. 

Começamos com uma troca inicial de informações de codec nas duas primeiras mensagens SIP 
(lembre-se que o SDP é usado para listar os codecs disponíveis, entre outras coisas). PRACK é uma 
“confirmação provisional”. Quando essas mensagens tiverem sido trocadas, mensagens PATH do RSVP, 
que contêm uma descrição da quantidade de recursos que serão exigidos, podem ser enviadas como o 
primeiro passo na reserva de recursos nas duas direções da chamada. Em seguida, mensagens RESV 
podem ser enviadas de volta para realmente reservar os recursos. Quando um RESV é recebido pelo 
telefone que inicia a chamada, ele pode enviar uma mensagem SDP atualizada, relatando o fato de 
que os recursos foram reservados em uma direção. Quando o telefone chamado tiver recebido essa 
mensagem e o RESV do outro telefone, ele pode começar a tocar e dizer ao outro telefone que os recursos 
agora estão reservados nas duas direções (com a mensagem SDP) e também notificar ao telefone que 
chama que ele está tocando. Daqui por diante, prossegue a sinalização SIP e o fluxo normal de mídia, 
semelhante ao que aparece na Figura 9.9. 

Novamente, vemos como a construção de aplicações exige que entendamos a interação entre dife- 
rentes blocos construtivos (SIP e RSVP neste caso). Os projetistas do SIP na realidade, fizeram algumas 
mudanças no protocolo para permitir essa intercalação de funções entre protocolos com diferentes 
tarefas, daí nossa ênfase neste livro em focalizar sistemas completos, em vez de apenas examinar uma 
camada ou componente isoladamente das outras partes do sistema. 


9.3 Serviços de infraestrutura 


Existem alguns protocolos que são essenciais para o funcionamento adequado da Internet, mas que não 
se encaixam no modelo estritamente em camadas. Um deles é o Sistema de Nomes de Domínio (DNS — 
Domain Name System) - não uma aplicação que os usuários normalmente chamam explicitamente, 
mas um serviço do qual quase todas as outras aplicações dependem. Isso porque o serviço de nomes é 
usado para traduzir os nomes de host em endereços de host; a existência de tal aplicação permite que 
os usuários de outras aplicações se refiram aos hosts remotos por nome, e não por endereço. Em outras 
palavras, um serviço de nomes normalmente é usado por outras aplicações, e não por seres humanos. 

Uma segunda função crítica é o gerenciamento de rede que, embora não tão familiar ao usuário co- 
mum, é a operação realizada com mais frequência pelos administradores de sistemas. O gerenciamento 





Capítulo 9º Aplicações 455 
ES 
ELSEVIER 


de rede é considerado um dos problemas difíceis no universo de redes e continua a ser assunto de muita 
pesquisa. A seguir, veremos alguns dos problemas e abordagens para solucionar o problema. 


9.3.1 Serviço de nomes (DNS) 


Na maior parte deste livro, estivemos usando endereços para identificar os hosts. Embora perfeitamente 
adequados para o processamento nos roteadores, os endereços não são muito amigáveis para serem 
usados por usuários. É por esse motivo que um nome unívoco normalmente também é atribuído a cada 
host em uma rede. Mesmo nesta seção, vimos protocolos de aplicação como HTTP usando nomes como 
www.princeton.edu. Agora, descrevemos como um serviço de nomes pode ser desenvolvido para mapear 
nomes amigáveis ao usuário em endereços amigáveis ao roteador. Os serviços de nomes às vezes são 
chamados middleware, pois preenchem uma lacuna entre as aplicações e a rede subjacente. 

Os nomes de host diferem dos endereços de host de duas maneiras importantes. Primeiro, eles 
normalmente são de tamanho variável e mmemônicos, facilitando sua memorização por humanos. (Por 
outro lado, os endereços numéricos de tamanho fixo são mais fáceis para os roteadores processarem.) 
Segundo, os nomes normalmente não contêm informações que ajudem a rede a localizar (rotear pacotes 
para) o host. Os endereços, em comparação, às vezes possuem informações de roteamento embutidas; 
endereços não hierárquicos (aqueles não divisíveis em partes que o compõem) são a exceção. 

Antes de entrarmos nos detalhes de como os hosts recebem nomes em uma rede, primeiro in- 
troduzimos alguma terminologia básica. Primeiro, um espaço de nomes define o conjunto de nomes 
possíveis. Um espaço de nomes pode ser não hierárquivo (os nomes não são divisíveis em componentes) 
ou hierárquicos (os nomes de arquivos do Unix são um exemplo óbvio). Segundo, o sistema de nomes 
mantém uma coleção de vínculos entre nomes e valores. O valor pode ser qualquer coisa que quisermos 
que o sistema de nomes retorne ao receber um nome; em muitos casos, ele é um endereço. Finalmente, 
um mecanismo de tradução é um procedimento que, quando invocado com um nome, retorna o valor 
correspondente. Um servidor de nomes é uma implementação específica de um mecanismo de tradução 
que está disponível em uma rede e que pode ser consultado pelo envio de uma mensagem a ele. 

Devido ao seu grande tamanho, a Internet possui um sistema de nomes particularmente bem 
desenvolvido em funcionamento — o sistema de nomes de domínio (DNS — Domain Name System). 
Portanto, usamos o DNS como uma estrutura para discutirmos o problema de nomes de hosts. Observe 
que a Internet nem sempre usou DNS. No início de sua história, quando havia poucas centenas de 
hosts na Internet, uma autoridade central chamada Network Information Center (NIC)' mantinha uma 
tabela não hierárquica de vínculos de nome e endereço; essa tabela era chamada hosts.txt. Sempre que 
uma organização queria acrescentar um novo host à Internet, o administrador daquela organização 
enviava uma mensagem de correio eletrônico para o NIC, indicando o par nome/endereço do novo 
host. Essa informação era inserida manualmente na tabela, a tabela modificada era enviada para as 
diversas instalações periodicamente e o administrador de sistemas em cada organização instalava a 
tabela em cada host da organização. A tradução de nomes, portanto, era implementada simplesmente 
por um procedimento que pesquisava o nome de um host na cópia local da tabela e retornava o endereço 
correspondente. 

Não deve ser surpresa que a abordagem de manter nomes em um arquivo hosts.txt passou a não 
funcionar bem à medida que o número de hosts na Internet começou a crescer. Portanto, em meados da 
década de 1980, o sistema de nomes de domínio foi desenvolvido. O DNS emprega um espaço de nomes 
hierárquico, em vez de um espaço de nomes não hierárquivo, e a “tabela” de vínculos que implementa 
esse espaço de nomes é repartida em partes independentes que são distribuídas pela Internet. Essas 
subtabelas ficam disponíveis nos servidores de nomes que podem ser consultados por meio da rede. 

O que acontece na Internet é que um usuário apresenta um nome de host a um programa de aplicação 
(possivelmente embutido em um nome composto, como um endereço de correio eletrônico ou URL), e 
esse programa contata o sistema de nomes para traduzir esse nome em um endereço de host. A aplicação, 
então, abre uma conexão com esse host passando a algum protocolo de transporte (por exemplo, TCP) 


7O acrônimo NIC pode ser traduzido literalmente como “Centro de Informações de Rede”, embora normalmente seja 
traduzido como “Núcleo de Informação e Coordenação” com o objetivo de não alterar o já bastante utilizado acrônimo. (N.T.) 
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Usuário 1 FIGURA 9.14 Nomes traduzidos em endereços, onde os números 1-5 
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o endereço IP do host. Essa situação é ilustrada (no caso do envio de e-mail) na Figura 9.14. Embora 
esta figura dê a entender que a tarefa de tradução de nome é muito simples, existem mais detalhes 
envolvidos, conforme veremos. 


Hierarquia de domínios 

O DNS implementa um espaço de nomes hierárquico para objetos da Internet. Ao contrário dos nomes 
de arquivo do Unix, que são processados da esquerda para a direita, com cada componente de nome 
separado por barras, os nomes do DNS são processados da direita para a esquerda e usam pontos como 
separadores. (Embora sejam processados da direita para a esquerda, os humanos leem nomes de domínio 
da esquerda para a direita.) Um exemplo de nome de domínio para um host é penguins.cs.princeton. 
edu. Observe que dissemos que os nomes de domínio são usados para nomear “objetos” da Internet. 
O que queremos dizer com isso é que o DNS não é estritamente usado para mapear nomes de host em 
endereços de host. É mais correto dizer que o DNS mapeia nomes de domínio em valores. No momento, 
consideramos que esses valores são endereços IP; voltaremos a esse assunto mais adiante nesta seção. 

Assim como na hierarquia de arquivos do Unix, a hierarquia do DNS pode ser visualizada como uma 
árvore, na qual cada nó na árvore corresponde a um domínio e as folhas na árvore correspondem aos 
hosts sendo nomeados. A Figura 9.15 contém um exemplo de uma hierarquia de domínios. Observe 
que não devemos atribuir qualquer semântica ao termo domínio além de simplesmente um contexto 
em que nomes adicionais podem ser definidos.? 

Na realidade, houve muita discussão enquanto a hierarquia de nomes de domínios estava sendo 
desenvolvida, com relação às convenções que governariam os nomes distribuídos perto do topo da 
hierarquia. Sem entrar em muitos detalhes, observe que a hierarquia não é tão larga no primeiro nível. 
Existem domínios para cada país, e mais “seis grandes” domínios: .edu, .com, .gov, .mil, .org e .net. 
Todos esses seis domínios foram baseados originalmente nos Estados Unidos (onde a Internet e o DNS 
foram inventados); por exemplo, somente instituições educacionais credenciadas nos Estados Unidos 
podem registrar um nome de domínio .edu. Nos últimos anos, o número de domínios de primeiro 


e 


FAAA LAAAAA 
Pd PANA 


ux01 --- ux04 


FIGURA 9.15 Exemplo de uma hierarquia de domínios. 


Pode ser confuso, mas a palavra domínio também é usada no roteamento da Internet, onde significa algo diferente do uso 
no DNS, sendo mais ou menos equivalente ao termo sistema autônomo. 
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FIGURA 9.16 Hierarquia de domínios repartida em zonas. 


nível foi expandido, parcialmente para lidar com a alta demanda por nomes de domínios .com. Alguns 
dos domínios de primeiro nível mais novos são .biz, .coop e .info. Outro desenvolvimento recente foi o 
suporte de nomes de domínio que são representados em conjuntos de caracteres diferentes do alfabeto 
latino, como Árabe e Chinês. 


Servidores de nomes 

A hierarquia completa de nomes de domínios só existe de forma abstrata. Agora, voltamos nossa atenção 
para a questão de como essa hierarquia é realmente implementada. O primeiro passo é particionar a 
hierarquia em subárvores, chamadas zonas. A Figura 9.16 mostra como a hierarquia dada na Figura 9.15 
poderia ser dividida em zonas. Cada zona pode ser considerada como sendo correspondente a alguma 
autoridade administrativa responsável por essa parte da hierarquia. Por exemplo, no nível superior 
da hierarquia forma-se uma zona controlada pela Corporação para Atribuição de Nomes e Números na 
Internet (ICANN -Internet Corporation for Assigned Names and Numbers). Abaixo dela existe uma zona 
que corresponde à Universidade de Princeton. Dentro dessa zona, alguns departamentos não querem 
ter a responsabilidade por administrar a hierarquia (e por isso permanecem na mesma zona no nível da 
universidade), enquanto outros, como o Departamento de Ciência da Computação (cs), administram 
sua própria zona no nível de departamento. 

A relevância de uma zona é que ela corresponde à unidade fundamental de implementação no 
DNS -o servidor de nomes. Especificamente, a informação contida em cada zona é implementada em 
dois ou mais servidores de nomes. Cada servidor de nomes, por sua vez, é um programa que pode ser 
acessado pela Internet. Clientes enviam consultas aos servidores de nomes, e os servidores de nomes 
respondem com a informação solicitada. Às vezes, a resposta contém a resposta final que o cliente 
deseja, e às vezes a resposta contém um ponteiro para outro servidor, que o cliente deverá consultar 
em seguida. Assim, do ponto de vista da implementação, é mais correto pensar no DNS como sendo 
representado por uma hierarquia de servidores de nomes do que por uma hierarquia de domínios, 
conforme ilustrado na Figura 9.17. 
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Observe que cada zona é implementada em dois ou mais servidores de nomes, por questão de 
redundância; ou seja, a informação ainda estará disponível mesmo que um servidor de nomes falhe. 
Por outro lado, determinado servidor de nomes é livre para implementar mais de uma zona. 

Cada servidor de nomes implementa a informação de zona como uma coleção de registros de recursos. 
Essencialmente, um registro de recursos é um vínculo entre nome e valor ou, mais especificamente, 
uma quíntupla que contém os seguintes campos: 


< Nome, Valor, Tipo, Classe, TTL > 


Os campos Nome e Valor são exatamente o que você esperaria, enquanto o campo Tipo especifica 
como o Valor deve ser interpretado. Por exemplo, Tipo = A indica que o Valor é um endereço IP Assim, 
registros A implementam o mapeamento nome-endereço que estivemos considerando. Outros tipos 
de registro incluem: 


e NS-O campo Valor indica o nome de domínio para um host executando um servidor de nomes 
que sabe como traduzir nomes dentro do domínio especificado. 

e CNAME -O campo Valor indica o nome canônico para determinado host; ele é usado para definir 
apelidos. 

e MX-O campo Valor indica o nome de domínio para um host executando um servidor de e-mail 
que aceita mensagens para o domínio especificado. 


O campo Classe foi incluído para permitir que entidades diferentes do NIC definam tipos de registros 
úteis. Até o momento, a única Classe amplamente utilizada é aquela usada pela Internet; ela é denotada 
por IN. Finalmente, o campo TTL (Time-To-Live) mostra por quanto tempo esse registro de recurso 
é válido. Ele é usado pelos servidores que mantêm registros de recursos de outros servidores em seu 
cache; quando o TTL expira, o servidor precisa remover o registro de seu cache. 

Para entender melhor como os registros de recursos representam as informações na hierarquia de 
domínios, considere os exemplos a seguir, retirados da hierarquia de domínios dada na Figura 9.15. 
Para simplificar os exemplos, ignoramos o campo TTL e consideramos a informação relevante apenas 
para um dos servidores de nomes que implementam cada zona. 

Primeiro, o servidor de nomes raiz contém um registro NS para cada servidor de nomes do domínio de 
nível superior (TLD — Top-Level Domain). Este registro identifica um servidor que pode traduzir consultas 
para essa parte da hierarquia do DNS (.edu e .com, neste exemplo). Ele também possui um registro 
A, que traduz esse nome para o endereço IP correspondente. Juntos, esses dois registros efetivamente 
implementam um ponteiro indo do servidor de nomes raiz para cada um dos servidores do TLD. 


< edu,a3.nstid.com,NS,IN > 

< a3.nstid.com, 192.5.6.32,A,IN > 

< com,a.gtld-servers.net,NS,IN > 

< a.gtld-servers.net,192.5.6.30,A,IN > 


Descendo um nível na hierarquia, o servidor a3.nstld.com tem registros para domínios .edu desta 
forma: 


< princeton.edu,dns.princeton.edu,NS,IN > 
< dns.princeton.edu,128.112.129.15,A,IN > 


Neste caso, obtemos um registro NS e um registro A para o servidor de nomes que é responsável pela 
parte princeton.edu da hierarquia. Esse servidor poderia ser capaz de traduzir diretamente algumas 
consultas (por exemplo, email.princeton.edu), enquanto redirecionaria outras para um servidor em 
outro nível na hierarquia (por exemplo, para uma consulta relativa a penguins.cs.princeton.edu). 
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< email.princeton.edu,128.112.198.35,A,IN > 
< penguins.cs.princeton.edu,dns1.cs.princeton.edu,NS,IN > 
< dns1.cs.princeton.edu,128.112.136.10,A,IN > 


Finalmente, um servidor de nomes de terceiro nível, como aquele administrado pelo domínio cs.prin- 
ceton.edu, contém registros A para todos os seus hosts. Ele também poderia definir um conjunto de 
apelidos (registros CNAME) para cada um desses hosts. Apelidos (ou aliases), às vezes, são apenas nomes 
convenientes (ou seja, mais curtos) para as máquinas, mas também podem ser usados para fornecer 
um nível de indireção. Por exemplo, www.cs.princeton.edu é um apelidos para o host chamado coreweb. 
cs.princeton.edu. Isso permite que o servidor Web do site seja transferido para outra máquina sem afetar 
os usuários remotos; eles simplesmente continuam a usar o apelido sem saber qual máquina executa 
atualmente o servidor Web do domínio. Os registros de troca de correio (MX) têm a mesma finalidade 
das aplicações de correio eletrônico — eles permitem que um administrador troque o host designado 
para receber e-mails pelo domínio sem ter que mudar o endereço de todas as pessoas. 


< penguins.cs.princeton.edu,128.112.155.166,A,IN > 

< WWw.cs.princeton.edu,coreweb.cs.princeton.edu, CNAME, IN > 
< coreweb.cs.princeton.edu,128.112.136.35,A,IN > 
<cs.princeton.edu,mail.cs.princeton.edu,MX,IN > 

< mail.cs.princeton.edu,128.112.136.72,A,IN > 


Observe que, embora os registros de origem possam ser definidos para praticamente qualquer tipo 
de objeto, o DNS normalmente é usado para nomear hosts (incluindo servidores) e sites. Ele não é 
usado para nomear pessoas individuais ou outros objetos, como arquivos ou diretórios; outros sistemas 
de nomes normalmente são usados para identificar tais objetos. Por exemplo, o X.500 é um sistema de 
nomes ISO projetado para facilitar a identificação de pessoas. Ele permite que você identifique uma 
pessoa por meio de um conjunto de atributos: nome, cargo, número de telefone, endereço postal e assim 
por diante. O X.500 provou-se ser muito desajeitado — e, de certa forma, foi usurpado por mecanismos de 
busca poderosos, agora disponíveis na Web —, mas por fim evoluiu para o LDAP (Lightweight Directory 
Access Protocol). O LDAP é um subconjunto do X.500, projetado originalmente como uma interface para 
o X.500 usada em PCs. Hoje, ele está ganhando popularidade, principalmente no nível empresarial, 
como um sistema para descobrir informações sobre os usuários. 


Tradução de nomes 

Dada uma hierarquia de servidores de nomes, agora considere a questão de como um cliente faz com que 
esses servidores traduzam um nome de domínio. Para ilustrar a ideia básica, suponha que o cliente queira 
traduzir o nome penguins.cs.princeton.edu com ajuda do conjunto de servidores dados na subseção 
anterior. O cliente primeiro envia uma consulta contendo esse nome aos servidores raiz (como veremos 
adiante, isso raramente acontece na prática, mas será suficiente para ilustrar a operação básica por 
enquanto). O servidor raiz, não podendo encontrar uma correspondência para o nome inteiro, retorna a 
melhor correspondência que tiver — o registro NS relativo a edu, que aponta para o servidor TLD a3.nstld. 
com. O servidor também retorna todos os registros que estão relacionados a esse registro, neste caso, o 
registro A para a3.nstld.com. O cliente, não tendo recebido a resposta que estava procurando, envia em 
seguida a mesma consulta ao servidor de nomes no host cujo IP é 192.5.6.32. Esse servidor também não é 
capaz de encontrar uma correspondência para o nome inteiro, e por isso retorna os registros NS e A corres- 
pondentes ao domínio princeton.edu. Mais uma vez, o cliente envia a mesma consulta de antes para o 
servidor no host de IP 128.112.129.15, e dessa vez recebe o registro NS e o registro A correspondentes para 
o domínio cs.princeton.edu. Desta vez, o servidor que pode resolver totalmente a consulta foi alcançado. 
Uma única consulta ao servidor em 128.112.136.10 gera o registro A para penguins.cs.princeton.edu, e 
o cliente descobre que o endereço IP correspondente é 128.112.155.166. 
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CONVENÇÕES DE NOMEAÇÃO 


Nossa descrição do DNS focaliza os mecanismos subjacentes, ou seja, como a hierarquia é repartida 
por vários servidores e como funciona o processo de tradução. Existe uma questão igualmente interessante, 
porém muito menos técnica, das convenções que são usadas para decidir os nomes a serem usados 
no mecanismo. Por exemplo, é convencionado que todas as universidades dos EUA estejam sob o domínio 
.edu, enquanto as universidades inglesas estejam sob o subdomínio .ac (acadêmico) do domínio .uk (United 
Kingdom - Reino Unido). 

O que devemos entender sobre convenções é que elas às vezes são definidas sem que qualquer um 
tome uma decisão explícita. Por exemplo, por convenção, um site esconde o host exato usado como sua 
central de e-mail por trás do registro MX. Uma alternativa teria sido adotar a convenção de enviar o e-mail 
para usuário O mail.cs.princeton.edu, assim como esperamos encontrar o diretório FTP público de um site 
em ftp.cs.princeton.edu e seu servidor Web em www.cs.princeton.edu. Este último é tão prevalente que muitas 
pessoas nem sequer observam que essa é apenas uma convenção. 

Também existem convenções no nível local, onde uma organização nomeia suas máquinas de acordo 
com algum conjunto de regras coerente. Dado que os nomes de host venus, saturno e marte estão entre 
os mais populares na Internet, não é difícil perceber uma convenção de nomeação comum. Porém, algumas 
convenções de nomeação de hosts são mais criativas. Por exemplo, um site chamou suas máquinas de ligado, 
desligado, falhou, reiniciando etc., resultando em declarações confusas como “reiniciando falhou” e “ligado 
está desligado”. Naturalmente, também existem nomes menos criativos, como no caso em que números 
inteiros são usados para dar nome às máquinas. 





Este exemplo ainda deixa em aberto algumas questões sobre o processo de tradução. A primeira 
questão é: como o cliente localizou o servidor raiz em primeiro lugar? Ou então, em outras palavras: 
como você traduz o nome do servidor que sabe como traduzir nomes? Esse é um problema fundamental 
em qualquer sistema de nomes, e a resposta é que o sistema precisa ser inicializado de alguma maneira. 
Nesse caso, o mapeamento de nome em endereço para um ou mais servidores raiz é bem conhecido, 
ou seja, publicado por algum meio fora do próprio processo de nomes. 

Porém, na prática, nem todos os clientes conhecem os servidores raiz. Ao invés disso, o programa 
cliente em execução em cada host da Internet é inicializado com o endereço de um servidor de nomes 
local. Por exemplo, todos os hosts no Departamento de Ciência da Computação em Princeton conhecem 
o servidor em dnsl.cs.princeton.edu. Esse servidor de nomes local, por sua vez, possui registros de 
recursos para um ou mais servidores raiz, por exemplo: 


< 'root',a.root-servers.net,NS,IN > 
< a.root-servers.net,198.41.0.4,A,IN > 


Assim, a tradução de um nome na realidade envolve um cliente consultando o servidor local, que por 
sua vez atua como um cliente que consulta os servidores remotos em favor do cliente original. Isso resulta 
nas interações cliente/servidor ilustradas na Figura 9.18. Uma vantagem desse modelo é que todos os 
hosts na Internet não precisam se manter atualizados sobre onde estão localizados os servidores raiz 
atuais; somente os servidores precisam saber a respeito da raiz. Uma segunda vantagem é que o servidor 
local consegue ver as respostas que chegam das consultas que são feitas por todos os clientes locais. O 
servidor local mantém essas respostas em cache e às vezes é capaz de traduzir consultas futuras sem 
ter que enviar mensagens para fora da rede. O campo TTL, contido nos registros de recursos retornados 
pelos servidores remotos, indica por quanto tempo cada registro pode ser mantido em cache com 
segurança. Esse mecanismo de construção de caches também pode ser usado mais acima na hierarquia, 
reduzindo a carga sobre a raiz e os servidores TLD. 

A segunda questão é como o sistema funciona quando um usuário submete um nome parcial (por 
exemplo, penguins) em vez de um nome de domínio completo (por exemplo, penguins.cs.princeton. 
edu). A resposta é que o programa cliente é configurado com o domínio local em que o host reside (por 
exemplo, cs.princeton.edu), e ele anexa essa cadeia de caracteres a quaisquer nomes simples antes de 
enviar uma consulta. 
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FIGURA 9.18 Tradução de nomes na prática, onde os números 1-10 mostram a sequência de etapas no processo. 


Só para ter certeza de que tudo ficou claro, já vimos até aqui três níveis diferentes de identificadores - nomes 
de domínio, endereços IP e endereços físicos de rede —, e o mapeamento dos identificadores em um nível 
para identificadores em outro nível ocorre em diferentes pontos na arquitetura da rede. Primeiro, os usuários 
especificam nomes de domínio quando interagem com a aplicação. Segundo, a aplicação contata os serviços 
do DNS para traduzir esse nome para um endereço IP; é esse endereço IP que é colocado em cada datagrama, 
e não o nome do domínio. (Como um aparte, esse processo de tradução envolve datagramas IP sendo 


enviados pela Internet, mas esses datagramas são endereçados a um host que executa um servidor de nomes, 
e não ao destino final.) Terceiro, o IP realiza o encaminhamento em cada roteador, o que normalmente 
significa que ele mapeia um endereço IP em outro; ou seja, ele mapeia o endereço do destino final no 
endereço do roteador no próximo salto. Finalmente, o IP contata o Protocolo de Tradução de Endereços 

(ARP — Address Resolution Protocol) para traduzir o endereço IP do próximo salto para o endereço físico dessa 
máquina; o próximo salto pode ser o destino final ou então um roteador intermediário. Os quadros enviados 
pela rede física possuem esses endereços físicos em seus cabeçalhos. 





9.3.2 Network Management (SNMP) 


Uma rede é um sistema complexo, tanto em termos do número de nós que estão envolvidos quanto 
em termos do conjunto de protocolos que podem estar sendo executados em qualquer nó. Mesmo 
que você esteja restrito a se preocupar com os nós dentro de um único domínio administrativo, como 
um campus universitário, pode haver dezenas de roteadores e centenas (ou ainda milhares) de hosts 
para gerenciar. Se você pensar em todo o estado que deve ser mantido e manipulado em qualquer um 
desses nós — por exemplo, tabelas de tradução de endereços, tabelas de roteamento, estado da conexão 
TCP e assim por diante -, então é fácil ficar deprimido com a possibilidade de ter que administrar todas 
essas informações. 

É fácil imaginar motivos para querer saber a respeito do estado de vários protocolos em diferentes 
nós. Por exemplo, você poderia querer monitorar o número de remontagens de datagrama IP que foram 
abortadas, a fim de determinar se o tempo limite para a remoção de datagramas montados parcialmente 
precisa ser ajustado. Como outro exemplo, você poderia querer monitorar a carga sobre diversos nós (ou 
seja, o número de pacotes enviados ou recebidos), a fim de determinar se novos roteadores ou enlaces 
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precisam ser acrescentados à rede. Naturalmente, você também precisa estar atento á evidência de 
hardware defeituoso e software com comportamento errôneo. 

O que acabamos de descrever é o problema de gerenciamento de rede, uma questão que se aplica a 
toda a arquitetura da rede. Como os nós que queremos monitorar são distribuídos, nossa única opção 
real é usar a rede para gerenciar a rede. Isso significa que precisamos de um protocolo que nos permita 
ler (e possivelmente escrever) várias informações de estado em diferentes nós da rede. O protocolo 
mais usado para essa finalidade é o Protocolo Simples de Gerenciamento de Rede (SNMP - Simple 
Network Management Protocol). 

O SNMP é essencialmente um protocolo de solicitação /resposta especializado, que admite dois tipos 
de mensagens de solicitação: as operações GET e SET. A primeira é usada para obter o estado de algum 
nó, e a segunda é usada para armazenar um novo estado em algum nó. (O SNMP também admite uma 
terceira operação, GET-NEXT, que explicamos mais adiante.) A discussão a seguir focaliza a operação 
GET, pois ela é utilizada com mais frequência. 

O SNMP é usado da maneira óbvia. Um administrador de sistemas interage com um programa cliente, 
que exibe informações sobre a rede. Esse programa cliente normalmente possui uma interface gráfica. 
Você pode imaginar que essa interface desempenha o mesmo papel de um navegador Web. Sempre 
que o administrador seleciona determinada informação que ele deseja ver, o programa cliente utiliza 
SNMP para solicitar essa informação do nó em questão. (O SNMP é executado em cima do UDE) Um 
servidor SNMP executando nesse nó recebe a solicitação, localiza a informação apropriada e a retorna 
ao programa cliente, que em seguida a exibe ao usuário. 

Há somente uma complicação nesse cenário que, se não fosse por isso, seria simples: como exata- 
mente o cliente indica qual informação ele deseja obter e, de modo semelhante, como o servidor sabe 
qual variável na memória ele deve ler para satisfazer a solicitação? A resposta é que o SNMP depende de 
uma especificação acompanhante, chamada Base de Informações de Gerenciamento (MIB - Management 
Information Base). A MIB define as partes específicas da informação — as variáveis MIB - que você pode 
obter de um nó da rede. 

A versão atual da MIB, chamada MIB-II, organiza as variáveis em dez grupos diferentes. Você per- 
ceberá que a maioria dos grupos corresponde a um dos protocolos descritos neste livro, e quase todas 
as variáveis definidas para cada grupo deverão ser familiares. Por exemplo: 


e Sistema: parâmetros gerais do sistema (nó) como um todo, incluindo onde o nó está localizado, 
por quanto tempo esteve ligado e o nome do sistema. 

e Interfaces: informações sobre todas as interfaces de rede (adaptadores) conectadas a esse nó, como o 
endereço físico de cada interface e quantos pacotes foram enviados e recebidos em cada interface. 

e Tradução de endereços: informações sobre o Address Resolution Protocol (ARP) e, em particular, 

o conteúdo dessa tabela de tradução de endereços. 

e IP: variáveis relacionadas ao IP incluindo sua tabela de roteamento, quantos datagramas ele 
encaminhou com sucesso e estatísticas sobre a remontagem de datagramas. Inclui contadores 
informando quantas vezes o IP descartou um datagrama por um ou outro motivo. 

e TCP: informações sobre conexões TCP como o número de aberturas passivas e ativas, o número 
de reinicializações, o número de eventos de expiração do tempo limite, configurações padrão de tempo 
limite e assim por diante. As informações por conexão persistem apenas enquanto a conexão existe. 

e UDP: informações sobre o tráfego UDP incluindo o número total de datagramas UDP que foram 
enviados e recebidos. 


Há também grupos para o Internet Control Message Protocol (ICMP), Exterior Gateway Protocol (EGP) 
e o próprio SNMP. O décimo grupo é usado por cenários específicos. 

Retornando à questão do cliente indicando exatamente que informação ele deseja obter de um nó, 
ter uma lista de variáveis MIB é apenas metade da batalha. Dois problemas permanecem. Primeiro, 
precisamos de uma sintaxe exata para o cliente usar a fim de indicar qual das variáveis MIB ele deseja 
obter. Segundo, precisamos de uma representação precisa para os valores retornados pelo servidor. Os 
dois problemas são resolvidos por meio da Notação de Sintaxe Abstrata Um (ASN.1 — Abstract Syntax 
Notation One). 
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Considere inicialmente o segundo problema. Como já vimos no Capítulo 7, as regras básicas de 
codificação (BER) da notação ASN.1 definem uma representação para diferentes tipos de dados, como 
os inteiros. A MIB define o tipo de cada variável e depois usa ASN.1/BER para codificar o valor contido 
nessa variável, conforme ele é transmitido pela rede. Em relação ao primeiro problema, o ASN.1 também 
define um esquema de identificação de objetos; esse sistema de identificação não é descrito no Capí- 
tulo 7. A MIB usa esse sistema de identificação para atribuir um identificador globalmente exclusivo a 
cada variável MIB. Esses identificadores são dados em uma notação de “ponto”, semelhante aos nomes 
de domínio. Por exemplo, 1.3.6.1.2.1.4.3 é o identificador da ASN.1 exclusivo para a variável MIB ipln- 
Receives relacionada ao IP; essa variável conta o número de datagramas IP que foram recebidos por 
esse nó. Nesse exemplo, o prefixo 1.3.6.1.2.1 identifica a base de dados MIB (lembre-se de que os IDs 
de objeto ASN.1 referem-se a todos os objetos possíveis no mundo), o 4 corresponde ao grupo IP e o 3 
final indica a terceira variável nesse grupo. 

Assim, o gerenciamento de rede funciona da seguinte maneira. O cliente SNMP coloca o identificador 
ASN.1 para a variável MIB que deseja obter na mensagem de solicitação e envia essa mensagem ao 
servidor. O servidor, então, mapeia esse identificador à variável local (ou seja, ao local da memória em 
que o valor dessa variável está armazenado), obtém o valor atual mantido nessa variável e usa ANS.l/BER 
para codificar o valor que envia de volta ao cliente. 

Há um detalhe final. Muitas das variáveis MIB são tabelas ou estruturas. A existência dessas variáveis 
compostas explicam o motivo para a operação GET-NEXT do SNMP Essa operação, quando aplicada a 
determinado ID de variável, retorna o valor dessa variável mais o ID da próxima variável, por exemplo, o 
próximo item na tabela ou o próximo campo na estrutura. Isso ajuda o cliente a percorrer os elementos 
de uma tabela ou estrutura. 


9.4 Redes overlay 


Desde o seu início, a Internet adotou um modelo claro, em que os roteadores dentro da rede são respon- 
sáveis por encaminhar pacotes da origem ao destino, e os programas de aplicação são executados nos 
hosts conectados às bordas da rede. O paradigma cliente/servidor, ilustrado pelas aplicações discutidas 
nas duas primeiras seções deste capítulo, certamente adere a esse modelo. 

Todavia, nos últimos anos, a distinção entre encaminhamento de pacotes e processamento de aplica- 
ções tornou-se menos nítida. Novas aplicações estão sendo distribuídas pela Internet e, em muitos casos, 
essas aplicações tomam suas próprias decisões de encaminhamento. Essas novas aplicações híbridas às 
vezes são implementadas estendendo roteadores e switches tradicionais para admitir uma quantidade 
modesta de processamento específico da aplicação. Por exemplo, os chamados switches nível 7 são 
colocados na frente dos clusters de servidores e encaminham solicitações HTTP a um servidor específico 
com base no URL solicitado. Contudo, as redes overlay, ou redes sobrepostas, estão rapidamente surgindo 
como o mecanismo preferido para a introdução de novas funcionalidades na Internet. 

Você pode pensar em um overlay como uma rede lógica implementada em cima de uma rede física. 
Por esta definição, a própria Internet é uma rede overlay em cima dos enlaces fornecidos pela antiga 
rede telefônica. A Figura 9.19 representa um overlay implementado em cima de uma rede subjacente. 
Cada nó no overlay também existe na rede subjacente; ele processa e encaminha pacotes de um modo 
específico, dependente da aplicação. Os enlaces que conectam os nós overlay são implementados 
como túneis através da rede subjacente. Múltiplas redes overlay podem existir em cima da mesma rede 
subjacente — cada uma implementando seu próprio comportamento específico da aplicação — e os 
overlays podem ser aninhados, um em cima do outro. Por exemplo, todas as redes overlay de exemplo 
discutidas nesta seção tratam a Internet de hoje como a rede subjacente. 

Já vimos exemplos de tunelamento, por exemplo, para implementar redes privadas virtuais (VPNs). 
Como uma rápida revisão, os nós em cada extremidade de um túnel tratam o caminho de múltiplos saltos 
entre eles como um único enlace lógico, onde os nós que são atravessados pelo túnel encaminham os 
pacotes com base no seu cabeçalho mais externo, nunca cientes de que os nós da extremidade anexaram 
um cabeçalho mais interno. Por exemplo, a Figura 9.20 mostra três nós overlay (A, Be C) conectados 
por um par de túneis. Nesse exemplo, o nó overlay B poderia tomar uma decisão de encaminhamento 
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FIGURA 9.19 Rede overlay disposta em cima de uma rede física. 














para os pacotes indo de A para C com base no cabeçalho mais interno (Cabl) e depois anexar um cabeça- 
lho mais externo (CabE) que identifica C como destino na rede subjacente. Os nós A, Be C são capazes 
de interpretar os cabeçalhos interno e externo, enquanto os roteadores intermediários só entendem o 
cabeçalho mais externo. De modo semelhante, A, B e C possuem endereços na rede overlay e na rede 
subjacente, mas eles não são necessariamente os mesmos; por exemplo, seu endereço subjacente pode- 
ria ser um endereço IP de 32 bits, enquanto seu endereço overlay poderia ser um endereço experimental 
de 128 bits. Na verdade, o overlay não precisa usar quaisquer endereços convencionais, podendo rotear 
com base em URLs, nomes de domínio, uma consulta XML ou até mesmo o conteúdo de um pacote. 


OVERLAYS E A OSSIFICAÇÃO DA INTERNET 


Dada sua popularidade e uso generalizado, é fácil esquecer que, em determinada época, a Internet era um 
laboratório para pesquisadores fazerem experimentos com redes de comutação de pacotes. Porém, quanto mais 
a Internet se tornava um sucesso comercial, menos útil ela se tornava como uma plataforma para experimentar 
novas ideias. Hoje, interesses comerciais moldam o desenvolvimento continuado da Internet. 

De fato, em 2001, um relatório do National Research Council apontou para a ossificação da Internet, 
tanto intelectualmente (a pressão por compatibilidade com os padrões atuais sufoca a inovação) quanto 
em termos da própria infraestrutura (é praticamente impossível que os pesquisadores afetem a infraestrutura 
básica). O relatório prosseguia observando que, ao mesmo tempo, surgia todo um novo conjunto de desafios 
que pode exigir uma abordagem nova. O dilema, de acordo com o relatório, é que 

.. tecnologias bem-sucedidas e amplamente adotadas estão sujeitas à ossificação, o que torna difícil 
introduzir novas capacidades ou, se a tecnologia atual seguir seu curso, substituí-la por algo melhor. 

Os participantes industriais existentes que atuam no setor geralmente não estão motivados a desenvolver 
ou implantar tecnologias que podem perturbar seu funcionamento... 

Encontrar o modo certo de introduzir tecnologias que podem perturbar a rede é um problema 
interessante. Essas inovações provavelmente realizam algumas coisas muito bem, mas em geral elas 
atrapalham a tecnologia presente em outras áreas importantes. Por exemplo, para introduzir uma nova 
estratégia de roteamento na Internet, você teria que construir um roteador que não apenas dê suporte a essa 
nova tecnologia, mas também concorra com os fornecedores já estabelecidos em termos de desempenho, 
confiabilidade, conjunto de ferramentas de gerenciamento e assim por diante. Essa é uma tarefa 
extremamente grande. O que o inovador precisa é de um meio de permitir que os usuários aproveitem a nova 
ideia sem ter que escrever as centenas ou milhares de linhas de código necessárias para dar suporte apenas 
ao sistema básico. 

As redes overlay oferecem exatamente essa oportunidade. Os nós overlay podem ser programados 
para dar suporte à nova capacidade ou recurso, e depois dependerem dos nós convencionais para oferecer 
a conectividade subjacente. Com o tempo, se a ideia empregada no overlay se demonstrar útil, pode haver 
motivação econômica para migrar a funcionalidade para o sistema básico, ou seja, acrescentá-la ao conjunto 
de recursos dos roteadores comerciais. Por outro lado, a funcionalidade pode ser tão complexa que uma 
camada overlay pode ser exatamente o lugar onde ela deve ser deixada. 
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FIGURA 9.20 Túnel de nós overlay através de nós 
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9.4.1 Overlays de roteamento 


O tipo mais simples de overlay é aquele que existe apenas para dar suporte a uma estratégia de rotea- 
mento alternativa; nenhum processamento adicional no nível de aplicação é realizado nos nós overlay. 
Você pode ver uma rede privada virtual (ver Seção 4.1.8) como um exemplo de um overlay de roteamento, 
mas que não define tanto uma estratégia ou algoritmo alternativo quanto define entradas de tabela de 
roteamento alternativas para serem processadas pelo algoritmo de encaminhamento IP padrão. Nesse 
caso em particular, considera-se que o overlay utiliza “túneis IP”, e a capacidade de utilizar essas VPNs 
é admitida na maioria dos roteadores comerciais. 

Suponha, por exemplo, que você queira usar um algoritmo de roteamento que os fornecedores de 
roteadores comerciais não quiseram incluir em seus produtos. Como você faria isso? Você poderia 
simplesmente executar seu algoritmo em um grupo de hosts finais e montar um túnel através de 
roteadores da Internet. Esses hosts se comportariam como roteadores na rede overlay: como hosts, eles 
provavelmente estão conectados à Internet apenas por um enlace físico, mas como um nó no overlay, 
eles estariam conectados a vários vizinhos através de túneis. 

Como os overlays, quase por definição, são um meio de introduzir novas tecnologias independente do 
processo de padronização, não existem overlays padrão que possamos apontar como exemplos. Em vez 
disso, ilustramos a ideia geral de overlays de roteamento descrevendo vários sistemas experimentais, 
propostos recentemente por pesquisadores de redes. 


Versões experimentais do IP 

Os overlays são ideais para a implantação de versões experimentais do IP que você tem esperanças 
que um dia assumam uma escala global. Por exemplo, o multicast IP (Seção 4.2) começou como uma 
extensão do IP e até hoje não está habilitado em muitos roteadores da Internet. O MBone (multicast 
backbone) era uma rede overlay que implementava o multicast IP em cima do roteamento unicast 
fornecido pela Internet. Diversas ferramentas de conferência multimídia foram desenvolvidas e im- 
plantadas no Mbone. Por exemplo, as reuniões da IETF - que levam uma semana e atraem milhares de 
participantes - geralmente são transmitidas por broadcast através do MBone. 

Assim como as VPNs, o MBone, utiliza túneis IP e endereços IP mas, diferente das VPNs, o MBone 
implementa um algoritmo de encaminhamento diferente — ele encaminha pacotes a todos os vizinhos 
na direção do fluxo usando a árvore de multicast de caminho mais curto. Como um overlay, os roteadores 
cientes do multicast fazem um túnel pelos roteadores legados, na esperança de que um dia não haja 
mais roteadores legados. 

O 6-BONE foi um overlay semelhante, usado para implantar IPv6 de modo incremental. Assim como 
o MBone, o 6-BONE utiliza túneis para encaminhar pacotes através de roteadores IPv4. Porém, ao con- 
trário do MBone, os nós 6-BONE não oferecem simplesmente uma nova interpretação dos endereços 
de 32 bits do IPv4. Em vez disso, eles encaminham pacotes com base no espaço de endereços de 128 
bits do IPv6. O 6-BONE também fornece suporte a multicast IPv6. 
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Multicast do sistema final 

Embora o multicast IP seja popular entre pesquisadores e certos segmentos da comunidade de redes, sua 
implantação na Internet global tem sido no mínimo limitada. Em resposta a isto, as aplicações baseadas 
em multicast, como videoconferência, recentemente passaram para uma estratégia alternativa, chamada 
multicast do sistema final. A ideia do multicast do sistema final é aceitar que o multicast IP nunca se 
tornará onipresente e, ao invés disso, deixar que os hosts finais que estão participando de determinada 
aplicação baseada em multicast implementem suas próprias árvores de multicast. 

Antes de descrevermos como funciona o multicast do sistema final, é importante entender primeiro 
que, diferente das VPNs e do MBone, o multicast do sistema final considera que somente os hosts da 
Internet (em contraste com os roteadores da Internet) participam do overlay. Além disso, esses hosts 
normalmente trocam mensagens entre si através de túneis UDP em vez de túneis IP facilitando a im- 
plementação como programas de aplicação comuns. Isso permite visualizar a rede subjacente como um 
grafo totalmente conectado, pois cada host na Internet é capaz de enviar uma mensagem a cada um dos 
outros hosts. Logo, de forma abstrata, o multicast do sistema final resolve o seguinte problema: começando 
com um grafo totalmente conectado, representando a Internet, o objetivo é encontrar a árvore de multicast 
embutida que cobre todos os membros do grupo. 

Como consideramos a Internet subjacente como estando totalmente conectada, uma solução simples 
seria conectar cada origem diretamente a cada membro do grupo. Em outras palavras, o multicast do 
sistema final poderia ser implementado com cada nó enviando mensagens de unicast a cada membro 
do grupo. Para ver o problema de se fazer isso, especialmente em comparação com a implementa- 
ção do multicast IP nos roteadores, considere a topologia de exemplo na Figura 9.21. A Figura 9.21(a) 
representa um exemplo de topologia física, em que R1 e R2 são roteadores conectados por um enlace 
transcontinental com pouca largura de banda; A, B, C e D são hosts finais; e os atrasos do enlace são 
dados como pesos das arestas. Supondo que A queira enviar uma mensagem de multicast para os 
outros três hosts, a Figura 9.21(b) mostra como a transmissão simplista usando unicast funcionaria. 
Isso certamente é indesejável, pois a mesma mensagem precisa atravessar o enlace A-R1 três vezes, 
e duas cópias da mensagem atravessam R1-R2. A Figura 9.21(c) representa a árvore de multicast IP 


R1 R2 (D) FIGURA 9.21 Árvores de multicast alternativas mapeadas sobre uma 
topologia física. 
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construída pelo protocolo de roteamento multicast por vetor de distâncias (DVMRP - Distance Vector 
Multicast Routing Protocol). Nitidamente, essa técnica elimina as mensagens redundantes. Porém, sem 
suporte dos roteadores, o melhor que você pode esperar com o multicast do sistema final é uma árvore 
semelhante à que aparece na Figura 9.21(d). O multicast do sistema final define uma arquitetura para 
construir essa árvore. 

A abordagem geral é dar suporte a vários níveis de redes overlay, cada um extraindo um subgrafo do 
overlay abaixo dele, até que tenhamos selecionado o subgrafo que a aplicação espera. Para o multicast 
do sistema final em particular, isso acontece em dois estágios: primeiro, construímos uma malha overlay 
simples em cima da Internet totalmente conectada, e depois selecionamos uma árvore de multicast 
dentro dessa malha. A ideia é ilustrada na Figura 9.22, novamente considerando os quatro hosts finais 
A, B, Ce D. A primeira etapa é crítica: quando tivermos selecionado uma malha overlay adequada, 
simplesmente executamos um algoritmo de roteamento multicast padrão (por exemplo, DVMRP) em 
cima dele para montar a árvore de multicast. Também podemos nos dar ao luxo de ignorar o problema 
de escalabilidade que o multicast englobando toda a Internet enfrenta, pois a malha intermediária 
pode ser selecionada para incluir apenas os nós que querem participar de um grupo de multicast em 
particular. 

A chave para a construção da malha overlay intermediária é selecionar uma topologia que corres- 
ponda aproximadamente à topologia física da Internet subjacente, mas temos que fazer isso sem que 
alguém nos diga como a Internet subjacente realmente se parece, pois estamos operando apenas nos 
hosts finais, e não nos roteadores. A estratégia geral é que os hosts finais meçam a latência de ida e 
volta até os outros nós e decidam acrescentar enlaces à malha somente quando gostarem do resultado. 
Vejamos como isso funciona. 

Primeiro, supondo que já exista uma malha, cada nó transmite a lista de todos os outros nós que 
acredita fazer parte da malha para seus vizinhos conectados diretamente. Quando um nó recebe essa 
lista de membros de um vizinho, ele incorpora essa informação à sua lista de membros e encaminha 
a lista resultante aos seus vizinhos. Essa informação por fim se propagará pela malha inteira, como em 
um protocolo de roteamento por vetor de distâncias. 

Quando um host deseja se juntar a um overlay multicast, ele precisa conhecer o endereço IP de 
pelo menos um outro nó já existente no overlay. Depois, ele envia uma mensagem de “associar-se à 
malha” a esse nó. Isso conecta o novo nó à malha por uma aresta até o nó conhecido. Em geral, o novo 
nó poderia enviar uma mensagem de associação a vários nós atuais, associando-se assim à malha por 
vários enlaces. Quando um nó é conectado à malha por um conjunto de enlaces, ele periodicamente 
envia mensagens “keep alive” (manter vivo) aos seus vizinhos, para que saibam que ele ainda deseja 
fazer parte do grupo. 

Quando um nó sai do grupo, ele envia uma mensagem de “sair da malha” aos seus vizinhos conecta- 
dos diretamente, e essa informação é propagada aos outros nós na malha por meio da lista de membros 





FIGURA 9.22 Árvore de multicast embutida em uma malha overlay. 
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descrita anteriormente. Como alternativa, um nó pode falhar, ou simplesmente decidir sair do grupo 
silenciosamente, caso em que seus vizinhos detectarão que ele não está mais enviando mensagens de 
“keep alive”. Algumas saídas de nó possuem pouco efeito sobre a malha, mas se um nó detectar que 
a malha ficou particionada devido a um nó que saiu, ele cria uma nova aresta para um nó em outra 
partição, enviando uma mensagem de “associar-se à malha”. Observe que vários vizinhos podem desco- 
brir simultaneamente que houve uma divisão na malha, levando à adição de diversas arestas cruzando 
as partições da malha. 

Conforme descrevemos até aqui, acabaremos com uma malha que é um subgrafo da Internet original, 
totalmente conectada, mas que pode ter desempenho abaixo do ideal, visto que (1) a seleção inicial de 
vizinhos acrescenta enlaces aleatórios à topologia, (2) o reparo de partição pode acrescentar arestas 
que são essenciais no momento, mas que não são úteis no longo prazo, (3) a composição do grupo pode 
mudar em virtude de entradas e saídas dinâmicas, e (4) as condições da rede subjacente podem mudar. 
O que precisa acontecer é que o sistema deve avaliar o valor de cada aresta, resultando em novas arestas 
sendo acrescentadas à malha e a arestas existentes sendo removidas com o passar do tempo. 

Para acrescentar novas arestas, cada nó i periodicamente sonda algum membro j aleatório que não está 
atualmente conectado na malha, mede a latência de ida e volta da aresta (i,j) e depois avalia a utilidade da 
inclusão dessa aresta. Se a utilidade estiver acima de determinado patamar, o enlace (i,j) é acrescentado 
à malha. A avaliação da utilidade da inclusão da aresta (i,j) pode ser algo semelhante a isto: 


AvaliaUtilidade(j) 

utilidade = O 

para cada membro m diferente de 1 
LA = latência atual até o nó m pela rota através da malha 
NL = nova latência ao nó m pela malha se aresta (i,j) for incluída 
se (NL < LA) então 

utilidade += (LA - NL)/LA 
retorna utilidade 


A decisão de remover uma aresta é semelhante, exceto que cada nó i calcula o custo de cada enlace 
até o vizinho atual j da seguinte forma: 


AvaliaCusto(j) 
Custo;= número de membros para os quais jusa j como próximo salto 
Custo;= número de membros para os quais jusa į como próximo salto 
retorna máximo(Custo; , Custo, 


Depois, ele obtém o vizinho com o menor custo e o remove se o custo estiver abaixo de determinado 
patamar. 

Finalmente, como a malha é mantida usando aquilo que é basicamente um protocolo por vetor de 
distâncias, é trivial executar o DVMRP para encontrar uma árvore de multicast apropriada na malha. 
Observe que, embora não seja possível provar que o protocolo recém-descrito resulte na rede de malha 
ideal, permitindo assim que o DVMRP selecione a melhor árvore de multicast possível, tanto a simulação 
quanto a vasta experiência prática sugerem que ele realiza um bom trabalho. 


Redes overlay resilientes 
Outra função que pode ser realizada por um overlay é aquela de encontrar rotas alternativas para as 
aplicações de unicast tradicionais. Esses overlays exploram a observação de que a desigualdade trian- 
gular não vale para a Internet. A Figura 9.23 ilustra o que queremos dizer com isso. Não é raro encon- 
trarmos três locais na Internet - vamos chamá-los de A, Be C -tais que a latência entre A e B seja maior 
que a soma das latências de A para C e de C para B. Ou seja, às vezes seria melhor enviar seus pacotes 
indiretamente por algum nó intermediário do que enviá-las diretamente ao destino. 

Como pode ser isso? Bem, o BGP nunca prometeu que encontraria a rota mais curta entre dois locais 
quaisquer; ele apenas tenta encontrar alguma rota. Para tornar as coisas mais complicadas, as rotas do 
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FIGURA 9.23 A desigualdade triangular não necessariamente vale nas redes. 


BGP são bastante influenciadas por questões políticas, por exemplo, quem está pagando a quem para 
transportar seu tráfego. Isso normalmente acontece, por exemplo, em pontos de troca de tráfego entre 
os principais provedores de backbone. Resumindo, não dever ser surpresa alguma que a desigualdade 
triangular não seja verdadeira na Internet. 

Como podemos explorar essa observação? O primeiro passo é observar que, em um algoritmo de 
roteamento, existe uma escolha fundamental escalabilidade e a obtenção da melhor rota. Por um lado, 
o BGP se expande até redes muito grandes, mas normalmente não seleciona a melhor rota possível, e é 
lento para adaptar-se a interrupções da rede. Por outro lado, se você se preocupasse apenas em encon- 
trar a melhor rota entre alguns locais, poderia realizar um trabalho melhor monitorando a qualidade de 
cada caminho que pudesse ser usado, permitindo assim a seleção da melhor rota possível a qualquer 
instante. 

Um overlay experimental, chamado rede overlay resiliente (RON - Resilient Overlay Network), 
faz exatamente isso. A escalabilidade da RON é restrita a apenas algumas dezenas de nós porque 
ela utiliza uma estratégia n x n para monitorar de perto (por meio de sondas ativas) três aspectos 
da qualidade do caminho - latência, largura de banda disponível e probabilidade de perdas — entre 
cada par de locais. Depois, o overlay consegue selecionar tanto a rota ideal entre qualquer par de 
nós quanto modificar rotas rapidamente se as condições na rede mudarem. A experiência mostra 
que a RON é capaz de fornecer melhorias de desempenho modestas às aplicações, porém, mais 
importante, ela se recupera de falhas da rede muito mais rapidamente. Por exemplo, durante um 
período de 64 horas em 2001, uma instância de RON sendo executada em 12 nós detectou 32 in- 
terrupções durante mais de 30 minutos, e ela foi capaz de recuperar-se de todas estas interrupções 
em menos de 20 segundos, na média. Esse experimento também sugeriu que o encaminhamento 
de dados através de apenas um nó intermediário geralmente é suficiente para a recuperação de 
falhas na Internet. 

Como a RON não foi projetada para ser um método escalável, não é possível utilizá-la para ajudar um 
host A qualquer a se comunicar com um host B qualquer; A e B precisam saber com antecedência que 
provavelmente se comunicarão, e depois se juntarem à mesma RON. Contudo, a RON parece uma boa 
ideia em certos ambientes, como na conexão de algumas dezenas de instalações corporativas através 
da Internet, ou para permitir que você e 50 dos seus amigos estabeleçam seu próprio overlay particular 
para executar alguma aplicação. Porém, a questão real é: o que acontece quando todos começarem 
a executar sua própria RON? A sobrecarga de milhões de RONs sondando caminhos agressivamente 
inundará a rede? E alguém verá um comportamento melhorado quando muitas RONs competirem pelos 
mesmos caminhos? Essas perguntas ainda permanecem sem resposta. 


470 REDES DE COMPUTADORES ELSEVIER 


Todos esses overlays ilustram um conceito fundamental para as redes de computadores em geral: virtualização.” 
Ou seja, é possível montar uma rede virtual a partir de recursos abstratos (lógicos) em cima de uma rede física, 
construída a partir de recursos físicos. Ademais, é possível empilhar essas redes virtualizadas uma em cima 

da outra e que várias redes virtuais coexistam no mesmo nível. Cada rede virtual, por sua vez, oferece novas 


funcionalidades que são valiosas para algum grupo de usuários, aplicações ou redes do nível superior. 





*O termo virtualização é usado muito, atualmente, no contexto da computação em centros de dados para se referir à virtua- 
lização de servidores usando hipervisores e tecnologias semelhantes, mas esse é na realidade um conceito bem mais amplo. 





9.4.2 Redes peer-to-peer 


Aplicações recentes de compartilhamento de música, como Napster? e KaZaA, introduziram o termo 
“peer-to-peer” ou “par-a-par” ao vernáculo popular. Mas o que significa exatamente para um sistema 
ser “peer-to-peer”? Certamente, no contexto do compartilhamento de arquivos MP3, isso significa não 
ter que baixar música de um local central, mas poder acessar arquivos de música diretamente de quem 
na Internet tiver uma cópia armazenada em seu computador. Em geral, então, poderíamos dizer que 
uma rede peer-to-peer permite que uma comunidade de usuários crie um reservatório de seus recursos 
(conteúdo, armazenamento, largura de banda de rede, largura de banda de disco, CPU), oferecendo 
acesso a um maior local de arquivamento, áudio e videoconferências com um maior número de pes- 
soas, buscas e operações computacionais mais complexas e assim por diante, do que qualquer usuário 
poderia dispor individualmente. 

Frequentemente, atributos como descentralizado e auto-organizável são mencionados quando se 
discute sobre redes peer-to-peer, significando que os nós individuais se organizam em uma rede sem 
qualquer coordenação centralizada. Se você pensar a respeito, termos como estes poderiam ser usados 
para descrever a própria Internet. Ironicamente, porém, o Napster não é um sistema peer-to-peer ver- 
dadeiro de acordo com essa definição, pois ele depende de um registro central de arquivos conhecidos, e 
os usuários precisam consultar esse diretório para descobrir que máquina fornece determinado arquivo. 
Somente a última etapa — baixar de fato o arquivo — ocorre entre máquinas que pertencem a dois usuários, 
mas isso não é um muito mais do que uma transação tradicional cliente/servidor. A única diferença é que 
o servidor pertence a alguém exatamente como você, em vez de pertencer a uma grande corporação. 

Assim, voltamos à pergunta original: o que há de interessante sobre as redes peer-to-peer? Uma 
resposta é que tanto o processo de localizar um objeto de interesse quanto o processo de obter esse 
objeto na sua máquina local acontecem sem que você precise contatar uma autoridade centralizada 
e, ao mesmo tempo, o sistema é capaz de se expandir para milhões de nós. Um sistema peer-to-peer 
que é capaz de realizar essas duas tarefas de uma maneira descentralizada é uma rede overlay, onde os 
nós são aqueles hosts que desejam compartilhar objetos de interesse (por exemplo, música e outros 
arquivos variados), e os enlaces (túneis) conectando esses nós representam a sequência de máquinas que 
você precisa visitar para buscar o objeto que deseja. Essa descrição se tornará mais clara depois de 
examinarmos dois exemplos. 


Gnutella 
O Gnutella é uma antiga rede peer-to-peer que tentou fazer uma distinção entre compartilhar música 
(que provavelmente infringe os direitos autorais de alguém) e o compartilhamento geral de arquivos (que 
deveria ser algo bom, pois fomos ensinados a compartilhar desde os dois anos de idade). O que há de 
interessante sobre o Gnutella é que ele foi um dos primeiros sistemas deste tipo a não depender de um 
registro de objetos centralizado. Em vez disso, os participantes do Gnutella se organizam em uma rede 
overlay semelhante à que mostramos na Figura 9.24. Ou seja, cada nó que executa o software Gnutella 
(ou seja, implementa o protocolo Gnutella) conhece algum conjunto de outras máquinas que também 
executam o software Gnutella. O relacionamento “A e B se conhecem” corresponde às arestas nesse 
grafo. (Mais adiante, explicaremos melhor como esse grafo é formado.) 

Sempre que o usuário em determinado nó deseja encontrar um objeto, o Gnutella envia uma 
mensagem de CONSULTA referente ao objeto — por exemplo, especificando o nome do arquivo — aos 
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O FIGURA 9.24 Exemplo de topologia de uma rede peer-to-peer Gnutella. 


Q 
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seus vizinhos no grafo. Se um dos vizinhos tiver o objeto, ele responde ao nó que lhe enviou a consulta 
com uma mensagem de RESPOSTA À CONSULTA, especificando onde o objeto pode ser obtido (por 
exemplo, um endereço IP e um número de porta TCP). Esse nó, mais tarde, utiliza mensagens de OBTER 
ou ENVIAR para acessar o objeto. Se o nó não puder resolver a consulta, ele encaminha a mensagem de 
CONSULTA para cada um de seus vizinhos (exceto aquele que enviou a consulta) e o processo se repete. 
Em outras palavras, o Gnutella inunda o overlay para localizar o objeto desejado. O Gnutella define um 
TTL em cada consulta, para que essa inundação não continue indefinidamente. 

Além do TTL e da cadeia de caracteres de consulta, cada mensagem de CONSULTA contém um iden- 
tificador de consulta (QID) exclusivo, mas não contém a identidade da origem da mensagem original. 
Em vez disso, cada nó mantém um registro das mensagens de CONSULTA que ele viu recentemente: 
tanto o QID quanto o vizinho que lhe enviou a CONSULTA. Ele usa esse histórico de duas maneiras. 
Primeiro, se o nó receber uma mensagem de CONSULTA com um QID que corresponde a um que foi 
visto recentemente, ele não encaminha a mensagem de CONSULTA. Isso serve para interromper os 
laços de encaminhamento mais rapidamente do que o TTL poderia ter feito. Segundo, sempre que o 
nó recebe uma RESPOSTA A CONSULTA proveniente de um vizinho seguinte, ele sabe encaminhar a 
resposta ao vizinho anterior, que lhe enviou a mensagem de CONSULTA originalmente. Desse modo, 
a resposta segue seu caminho de volta ao nó original, sem que qualquer dos nós intermediários saibam 
quem quis localizar esse objeto específico em primeiro lugar. 

Retornando à questão de como o grafo evolui, um nó certamente precisa conhecer pelo menos um 
outro nó quando ele se associa a uma Gnutella. O novo nó é anexado ao overlay pelo menos por este 
único enlace. Depois disso, determinado nó descobre sobre outros nós como resultado das mensagens 
RESPOSTA À CONSULTA, tanto para objetos que solicitou quanto para respostas que passem por ele. 
Um nó é livre para decidir qual dos nós que ele descobre dessa maneira ele deseja manter como vizi- 
nho. O protocolo Gnutella fornece mensagens de PING e de PONG por meio das quais um nó sonda se 
determinado vizinho ainda existe ou não, e esse vizinho responde, respectivamente. 

Deve ficar claro que o Gnutella não é um protocolo particularmente inteligente, e sistemas subse- 
quentes tentaram melhorá-lo. Uma dimensão ao longo da qual são possíveis melhorias está em como 
as consultas são propagadas. A inundação possui a propriedade interessante de garantir a localização 
do objeto desejado com o menor número de saltos possível, mas ela não escala muito bem. É possível 
encaminhar consultas aleatoriamente, ou de acordo com a probabilidade de sucesso com base em 
resultados passados. Uma segunda dimensão é replicar os objetos proativamente, pois quanto mais cópias 
de determinado objeto existirem, mais fácil deve ser localizar uma cópia. Como alternativa, você poderia 
desenvolver uma estratégia completamente diferente, que é o assunto que consideramos em seguida. 


Overlays estruturados 

Ao mesmo tempo em que os sistemas de compartilhamento de arquivos têm lutado para preen- 
cher o vazio deixado pelo Napster, a comunidade de pesquisa tem explorado um projeto alternativo 
para as redes peer-to-peer. Vamos nos referir a essas redes como estruturadas, para diferenciá-las do 
modo essencialmente aleatório (não estruturado) com que uma rede Gnutella evolui. Os overlays 
não estruturados, como o Gnutella, empregam algoritmos triviais de construção e manutenção do over- 
lay, mas o melhor que eles podem oferecer é uma pesquisa não confiável e aleatória. Em comparação, 
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os overlays estruturados são projetados para terem a forma de uma estrutura de grafo específica, per- 
mitindo a localização confiável e eficiente dos objetos (atraso probabilisticamente limitado), ao custo 
de complexidade adicional durante a construção e a manutenção do overlay. 

Se você pensar no que estamos tentando fazer em um alto nível, existem duas perguntas a considerar: 
(1) como mapeamos objetos em nós e (2) como roteamos solicitações para o nó que é responsável por 
determinado objeto? Começamos com a primeira pergunta, que tem um enunciado simples: como 
mapeamos um objeto com nome x ao endereço de algum nó n que é capaz de enviar esse objeto? 
Embora as redes peer-to-peer tradicionais não tenham controle sobre qual nó hospeda o objeto x, se 
pudéssemos controlar como os objetos são distribuídos pela rede, poderíamos realizar um trabalho 
melhor de localização desses objetos mais adiante. 

Uma técnica bem conhecida para mapear nomes em endereços é usar uma tabela de hash, de modo 
que 


hash(x) >n 

implica que o objeto x é colocado inicialmente no nó n e, mais tarde, um cliente tentando localizar x só 
teria que calcular o hash de x para determinar que ele está no nó n. Uma abordagem baseada em hash 
tem a propriedade interessante de que ela tende a espalhar os objetos uniformemente pelo conjunto 
de nós, mas os algoritmos de hash simples sofrem de uma falha fatal: quantos valores possíveis de n 
devemos permitir? (Usando a terminologia dos mecanismos de cálculo de hash, quantos baldes deverão 
existir?) Ingenuamente, poderíamos decidir que existem, digamos, 101 valores de hash possíveis, e usar 
uma função de hash modular; ou seja: 


hash(x) 
retorna x % 101 


Infelizmente, se houver mais de 101 nós desejando hospedar objetos, então não poderemos apro- 
veitar todos eles. Por outro lado, se selecionarmos um número maior do que o maior número de nós 
possível, então haverá alguns valores de x que serão traduzidos em endereços para um nó que não 
existe. Há também o problema não tão pequeno de traduzir o valor retornado pela função de hash em 
um endereço IP real. 

Para resolver esses problemas, as redes peer-to-peer estruturadas utilizam um algoritmo conhecido 
como hash coerente, que divide um conjunto de objetos x uniformemente por um espaço de identi- 
ficadores grande. A Figura 9.25 permite visualizar um espaço de identificadores de 128 bits como um 
círculo, na qual usamos o algoritmo para colocar tanto objetos 


rede j 


a Ed FIGURA 9.25 Nós e objetos são mapeados (via hash) para o espaço de IDs, 
O, -i de modo que um objeto é mantido no nó mais próximo a ele desse 
espaço. 
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hash(nome objeto) >id obj 
quanto nós 
hash(endereço IP)>id nó 


nesse círculo. Como um espaço de identificadores de 128 bits é muito grande, é pouco provável que um 
objeto tenha o mesmo hash que o endereço IP de uma máquina terá. Para considerar essa improbabi- 
lidade, cada objeto é mantido no nó cujo identificador é o mais próximo, nesse espaço de 128 bits, ao 
identificador do objeto. Em outras palavras, a ideia é usar uma função de hash de alta qualidade para 
mapear nós e objetos no mesmo espaço de identificadores grande, esparso; depois, você mapeia objetos 
para nós por proximidade numérica de seus respectivos identificadores. Assim como o mecanismo de 
hash normal, isso distribui os objetos de modo razoavelmente uniforme entre os nós, mas, diferente 
do mecanismo de hash normal, somente um pequeno número de objetos precisa se mover quando um 
nó (balde de hash) se junta ou sai do grupo. 

Agora, vejamos a segunda pergunta: Como um usuário que deseja acessar o objeto x saberá qual 
nó está mais próximo do identificador de x nesse espaço? Uma resposta possível é que cada nó mante- 
nha uma tabela completa de identificadores de nós e seus endereços IP associados, mas isso não seria 
prático para uma rede grande. A alternativa, que é a abordagem utilizada pelas redes peer-to-peer 
estruturadas, é rotear uma mensagem para esse nó! Em outras palavras, se construirmos um overlay 
de um modo inteligente — que é o mesmo que dizer que precisamos escolher entradas para a tabela de 
roteamento de um nó de um modo inteligente —, então encontraremos um nó simplesmente roteando 
uma mensagem em sua direção. Coletivamente, essa abordagem às vezes é chamada de tabela de hash 
distribuída (DHT — Distributed Hash Table), visto que, conceitualmente, a tabela de hash é distribuída 
por todos os nós na rede. 

A Figura 9.26 ilustra o que acontece para um espaço de identificadores de 28 bits. Para manter a 
discussão a mais concreta possível, consideramos a técnica usada por uma rede peer-to-peer específica, 
chamada Pastry. Outros sistemas funcionam de maneira semelhante. (Veja os artigos citados na seção 
“Leitura adicional” para obter outros exemplos.) 

Suponha que você esteja no nó cujo identificador é 65a1fc (em hexadecimal) e esteja tentando 
localizar o objeto cujo identificador é d46a1c. Você percebe que seu identificador não compartilha nada 
com o identificador do objeto, mas você conhece um nó que compartilha pelo menos o prefixo d. Esse 
nó está mais próximo ao objeto do que você no espaço de identificadores de 128 bits, e por isso você 
encaminha a mensagem para ele. (Não indicamos o formato da mensagem sendo encaminhada, mas 
você pode pensar nela como dizendo: “Localize o objeto d46a1c”.) Supondo que o nó di3da3 conheça 
outro nó que compartilhe um prefixo ainda maior com o objeto, ele encaminha a mensagem adiante. 
Esse processo de se mover para mais perto no espaço de identificadores continua até que você atinja 
um nó que não conheça um nó mais perto do objeto. Esse nó, por definição, é aquele que armazena 







d467c4 
d462ba 


d4213f 


di3da3 


FIGURA 9.26 Objetos são localizados via roteamento 


locate(d46a1c) através da rede overlay peer-to-peer. 
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o objeto.” Lembre-se de que, enquanto nos movemos logicamente pelo “espaço de identificadores”, a 
mensagem está realmente sendo encaminhada, nó a nó, através da Internet subjacente. 

Cada nó mantém uma tabela de roteamento (veja mais sobre ela logo adiante) e os endereços IP de um 
pequeno conjunto de identificadores de nó numericamente maiores e menores. Isso é chamado de 
conjunto de folhas do nó. A importância do conjunto de folhas é que, quando uma mensagem é roteada 
para qualquer nó no mesmo conjunto de folhas do nó que hospeda o objeto, esse nó pode encaminhar 
a mensagem diretamente para o destino final. Em outras palavras, o conjunto de folhas facilita a entrega 
correta e eficiente de uma mensagem ao nó numericamente mais próximo, embora possa haver vários 
nós compartilhando um prefixo de tamanho máximo com o identificador do objeto. Além disso, um 
conjunto de folhas torna o roteamento mais robusto, pois qualquer um dos nós em um conjunto de 
folhas pode rotear uma mensagem tão bem quanto qualquer outro nó no mesmo conjunto. Assim, se um 
nó não puder progredir no roteamento de uma mensagem, um de seus vizinhos no conjunto de folhas 
pode ser capaz de fazê-lo. Resumindo, o procedimento de roteamento é definido da seguinte forma: 


Rotear(D) 
se D está dentro do alcance do meu conjunto de folhas 
encaminha para membro numericamente mais próximo no conjunto de folhas 
senão 
t= tamanho do prefixo compartilhado 
d = valor do dígito na posição tdo endereço de D 
se TabRot[t,d] existe 
encaminha para TabRot[t,d] 
senão 
encaminha para nó conhecido cujo prefixo é pelo menos do 
mesmo tamanho e numericamente mais próximo desse nó 


A tabela de roteamento, denotada por TabRot, é um vetor bidimensional. Ela possui uma linha 
para cada dígito hexa em um identificador (existem 32 desses dígitos em um identificador de 128 bits) 
e uma coluna para cada valor hexa (obviamente, existem 16 desses valores). Cada entrada na linha i 
compartilha um prefixo de tamanho i com esse nó, e dentro dessa linha, a entrada na coluna j tem o 
valor hexa j na posição i+ 1. A Figura 9.27 mostra as três primeiras linhas de uma tabela de roteamento de 
exemplo para o nó 65a1fcx, onde x indica um sufixo não especificado. Essa figura mostra o prefixo do 
identificador que tem maior correspondência com cada entrada na tabela. Ela não mostra o valor de 
fato contido na entrada — o endereço IP do próximo nó para o qual rotear a mensagem. 

A adição de um nó ao overlay funciona de modo semelhante ao roteamento de uma “mensagem de 
localizar objeto” para um objeto. O novo nó precisa conhecer pelo menos um membro atual do overlay. Ele 


2» 


pede a esse membro para rotear uma “mensagem de adicionar nó” até o nó numericamente mais próximo 
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Linha 3 
FIGURA 9.27 Exemplo de tabela de roteamento no nó 
com id 65alfcx. 





























Para ser mais exato, em muitos esquemas este nó não necessariamente tem uma cópia física do objeto, mas sim uma lista 
de nós que de fato têm uma cópia deste objeto. Esta lista é então devolvida como resposta à mensagem de consulta. (N.T.) 
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addnode(d46a1c) 





FIGURA 9.28 Incluindo um nó à rede. 


ao ID do nó que está se juntando à rede, como mostra a Figura 9.28. É por meio desse processo de roteamento 
que o novo nó descobre a respeito dos outros nós com um prefixo compartilhado e é capaz de iniciar o 
preenchimento de sua tabela de roteamento. Com o tempo, quando outros nós se juntarem ao overlay, os 
nós existentes também terão a opção de incluir informações sobre o nó recém-chegado em suas tabelas de 
roteamento. Eles fazem isso quando o novo nó acrescenta um prefixo mais longo do que eles atualmente têm 
em sua tabela. Os vizinhos nos conjuntos de folhas também trocam tabelas de roteamento entre si, o que 
significa que, com o passar do tempo, as informações de roteamento se propagam através do overlay. 

Você pode ter notado que, embora os overlays estruturados ofereçam um limite probabilístico para 
o número de saltos de roteamento exigidos para localizar determinado objeto — o número de saltos na 
rede Pastry é limitado por logısN, onde N é o número de nós no overlay —, cada salto pode contribuir 
com um atraso substancial. Isso porque cada nó intermediário pode estar em um local qualquer na In- 
ternet. (No pior caso, cada nó está em um continente diferente!) De fato, em uma rede overlay de alcance 
mundial usando o algoritmo descrito anteriormente, o atraso esperado para cada salto corresponde 
ao atraso médio entre todos os pares de nós na Internet! Felizmente, podemos fazer muito melhor na 
prática. A ideia é escolher cada entrada da tabela de roteamento de modo que a entrada se refira a um 
nó próximo na rede física subjacente, dentre todos os nós com um prefixo de identificador que seja 
apropriado para a entrada.!º Acontece que fazer isso leva a atrasos de roteamento fim a fim cujo valor 
não fica muito superior ao atraso entre os nós de origem e de destino. 

Finalmente, a discussão até este ponto esteve concentrada no problema geral de localizar objetos em 
uma rede peer-to-peer. Com essa infraestrutura de roteamento, é possível montar diferentes serviços. 
Por exemplo, um serviço de compartilhamento de arquivos usaria nomes de arquivos como nomes de 
objetos. Para localizar um arquivo, você primeiro transformaria seu nome (usando uma função de hash 
hash) em um identificador de objeto correspondente, e depois rotearia uma “mensagem de localizar 
objeto” para esse identificador. O sistema também poderia replicar cada arquivo em vários nós, a fim de 
melhorar a disponibilidade. O armazenamento de várias cópias no conjunto de folhas do nó para o qual 
determinado arquivo normalmente é roteado seria um modo de fazer isso. Lembre-se que, embora esses 
nós sejam vizinhos no espaço de identificadores, eles provavelmente estão fisicamente distribuídos pela 
Internet. Assim, embora uma falta de energia em uma cidade inteira possa desligar fisicamente réplicas 
próximas de um arquivo em um sistema de arquivos tradicional, uma ou mais réplicas provavelmente 
sobreviveriam a tal falha em uma rede peer-to-peer. 


1Coletivamente, mecanismos que tentam melhorar a distribuição de identificadores em uma rede peer-to-peer com base 
em alguma métrica (por exemplo, distância geográfica ou latência) são conhecidos como “mecanismos de localidade”. (N.T.) 
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Serviços que não sejam de compartilhamento de arquivos também podem ser montados sobre 
tabelas de hash distribuídas. Considere, por exemplo, as aplicações de multicast. Em vez de construir 
uma árvore de multicast a partir de uma malha, você poderia construir a árvore a partir das arestas de 
um overlay estruturado, amortizando assim os custos de construção e manutenção do overlay por várias 
aplicações e grupos de multicast. 


BitTorrent 

O BitTorrent é um protocolo de compartilhamento de arquivos peer-to-peer, idealizado por Bram 
Cohen. Ele é baseado na replicação do arquivo ou, mais exatamente, na replicação de segmentos 
do arquivo, que são chamados de pedaços. Qualquer pedaço em particular normalmente pode ser 
baixado de vários membros, mesmo que apenas um membro tenha o arquivo inteiro. O benefício 
principal da replicação do BitTorrent é evitar o gargalo de ter apenas uma fonte para um arquivo. 
Isso é particularmente útil quando você considera que qualquer computador possui uma velocidade 
limitada em que poderá servir arquivos por meio de sua conexão de saída para a Internet, que 
normalmente é um limite muito baixo devido à natureza assimétrica da maioria das redes de banda 
larga. A beleza do BitTorrent é que a replicação é um efeito colateral natural do processo de obtenção 
de um arquivo: assim que um membro obtém um pedaço em particular, ele se torna outra fonte para 
esse pedaço. Quanto maior o número de membros obtendo pedaços do arquivo, mais replicação 
deste pedaço ocorrerá, distribuindo a carga proporcionalmente, e mais largura de banda total fica 
disponível para o compartilhamente do arquivo com outros membros. Os pedaços são obtidos em 
ordem aleatória!! para evitar uma situação em que os membros acabem precisando todos do mesmo 
conjunto de pedaços. 

Cada arquivo é compartilhado por meio de sua própria rede BitTorrent independente, chamada de 
enxame (swarm). (Um enxame poderia potencialmente compartilhar um conjunto de arquivos, mas 
descrevemos o caso do arquivo único para simplificar.) O ciclo de vida de um enxame típico é o seguinte. 
O enxame começa como um membro isolado, com uma cópia completa do arquivo. Um nó que deseja 
obter o arquivo se junta ao enxame, tornando-se seu segundo membro, e começa a obter pedaços do 
arquivo a partir do membro original. Ao fazer isso, ele se torna outra fonte para os pedaços que obteve, 
mesmo que ainda não tenha obtido o arquivo inteiro. (Na verdade, é comum que os membros deixem 
o enxame quando tiverem concluído seus downloads, embora sejam encorajados a permanecerem por 
mais tempo.) Outros nós se juntam ao enxame e começam a obter pedaços de vários membros, não 
apenas do membro original. Ver Figura 9.29. 

Se o arquivo permanecesse com uma alta demanda, com um fluxo de membros substituindo aqueles 
que saíram do enxame, o enxame poderia permanecer ativo indefinidamente; se não, ele poderia enco- 
lher e incluir apenas o membro original, até que novos membros se juntem ao enxame.!? 

Agora que você tem uma visão geral do BitTorrent, podemos perguntar como as solicitações são 
roteadas para os membros que possuem determinado pedaço. Para fazer solicitações, um nó que 
deseja obter o arquivo primeiro precisa se juntar ao enxame. Ele começa obtendo um arquivo .torrent 
contendo metainformações sobre o arquivo desejado e sobre o enxame. O arquivo .torrent, que pode 
ser facilmente replicado, normalmente sendo obtido de um servidor Web que é descoberto seguindo 
links de páginas Web. Ele contém: 


e O tamanho do arquivo alvo. 

e O tamanho dos pedaços. 

e Valores de hash SHA-1 (Seção 8.1.4) pré-calculados a partir de cada pedaço. 
e O URL do rastreador do enxame. 


HPara ser mais exato, o BitTorrent adota a estratégia de “mais raros primeiro”: a cada instante um membro tenta obter o 
pedaço menos facilmente encontrado na rede, ou seja, aquele disponível em um menor número de outros membros. (N.T.) 
!2Membros que têm o arquivo completo no exame são chamados de seeders (“semeadores”), enquanto membros que ainda 
não obtiveram todos os pedaços são chamados de leechers (“sanguessugas”). Mesmo que o membro original deixe o enxame, 
outros seeders (ou um grupo de leechers que, em conjunto, tenham todos os pedaços) podem tomar seu lugar, mantendo 
o enxame ativo. (N.T.) 
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FIGURA 9.29 Membros em um enxame BitTorrent obtêm pedaços de membros que podem ainda não ter o arquivo completo. 


Um rastreador (ou tracker) é um servidor que rastreia os membros atuais de um enxame. Veremos, 
mais adiante, que o BitTorrent pode ser estendido para eliminar esse ponto de centralização, com seu 
potencial para apresentar gargalos ou falhas. 

O nó que deseja obter o arquivo então se junta ao enxame, tornando-se um membro, enviando 
uma mensagem ao rastreador com seu endereço de rede e um identificador de membro, que é gerado 
aleatoriamente para si mesmo. A mensagem também transporta um valor de hash SHA-1 correspondente 
à parte principal do arquivo .torrent, que é usado como um identificador de enxame. 

Vamos chamar o novo membro de P O rastreador responde a P com uma lista parcial de membros, 
fornecendo seus identificadores e endereços de rede, e P estabelece conexões, usando TCP com alguns 
desses membros. Observe que P está conectado diretamente a apenas um subconjunto do enxame, 
embora possa decidir entrar em contato com outros membros ou, até mesmo, solicitar mais membros 
do rastreador. Para estabelecer uma conexão BitTorrent com um membro específico depois que sua 
conexão TCP tiver sido estabelecida, P envia o identificador de membro do próprio P e o identificador 
do enxame, e o membro responde com seu identificador de membro e identificador de enxame. Se os 
identificadores de enxame forem diferentes, ou se o identificador do membro que envia a resposta não 
for o que P espera, a conexão é abortada. 

A conexão BitTorrent resultante é simétrica: cada extremidade pode obter pedaços da outra. Cada 
extremidade começa enviado à outra um mapa de bits relatando quais pedaços ela tem, de modo que 
cada membro conheça o estado inicial do outro. Sempre que o membro fazendo o download do arquivo 
(D) terminar de obter outro pedaço, ele envia uma mensagem identificando esse pedaço a cada um dos 
membros aos quais está conectado diretamente, de modo que esses membros possam atualizar sua 
representação interna do estado de D. Essa, por fim, é a resposta à pergunta de como uma solicitação 
de download de um pedaço é roteada para um membro que tem o pedaço, pois isto significa que cada 
membro sabe quais membros conectados diretamente têm o pedaço. Se D precisa de um pedaço que 
nenhuma de suas conexões tem, ele pode se conectar a mais membros ou a membros diferentes (ele 
pode obter mais do rastreador) ou ocupar-se com outros pedaços, na esperança de que algumas de suas 
conexões obtenham o pedaço faltante a partir das conexões delas. 

Como os objetos — neste caso, pedaços — são mapeados em nós membros? Naturalmente, cada 
membro em algum momento obtém todos os pedaços, de modo que a pergunta na realidade é quais 
pedaços um membro tem em determinado momento antes que tenha todos os pedaços ou, de modo 
equivalente, sobre a ordem em que um membro obtém os pedaços. A resposta é que eles obtêm os 
pedaços em uma ordem aleatória, para evitar que eles tenham um subconjunto ou superconjunto 
estrito dos pedaços de quaisquer de seus pares. 

O BitTorrent descrito até aqui utiliza um rastreador central que constitui um ponto único de fa- 
lha para o enxame, e potencialmente poderia ser um gargalo de desempenho. Além disso, fornecer 
um rastreador pode ser um incômodo para alguém que gostaria de tornar um arquivo disponível via 
BitTorrent. As versões mais novas do BitTorrent possuem suporte adicional a enxames “sem rastreador”, 
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que usam uma implementação baseada em DHT. O software cliente BitTorrent que é capaz de operar 
sem rastreador implementa não apenas um membro do BitTorrent, mas também o que chamaremos de 
localizador de membros (a terminologia do BitTorrent é simplesmente nó) que, obviamente, o membro 
utiliza para localizar membros. 

Localizadores de membros formam sua própria rede overlay, usando seu próprio protocolo em 
cima do UDP para implementar uma DHT. Além disso, uma rede de localizadores de membros inclui 
localizadores cujos membros associados pertencem a diferentes enxames. Em outras palavras, enquanto 
cada enxame forma uma rede distinta de membros BitTorrent, uma rede de localizadores de membros, 
em vez disso, gera enxames. 

Localizadores de membros geram aleatoriamente seus próprios IDs de localizador, que possuem o 
mesmo tamanho (160 bits) dos IDs de enxame. Cada localizador mantém uma tabela modesta, contendo 
principalmente localizadores (e seus membros associados) cujos IDs estão próximos aos seus, mais al- 
guns localizadores cujos IDs estão mais distantes. O algoritmo a seguir garante que os localizadores cujos 
IDs estão mais próximos de determinado ID de enxame provavelmente conheçam os membros desse 
enxame; o algoritmo oferece simultaneamente um modo de procurar por eles. Quando um localizador 
L precisa encontrar membros de um enxame específico, ele envia uma solicitação aos localizadores em 
sua tabela cujos IDs são próximos do ID desse enxame. Se um localizador contatado conhece algum dos 
membros desse enxame, o localizador responde com a informação de contato deles. Caso contrário, ele 
responde com a informação de contato dos localizadores em sua tabela que estão próximos do enxame, 
de modo que L possa consultar esses localizadores de forma iterativa. 

Depois que a busca termina, quando não existem localizadores mais próximos do enxame, L insere 
sua própria informação de contato e a informação de contato do membro a ele associado nos locali- 
zadores mais próximos do enxame. O resultado final é que os membros de determinado enxame são 
inseridos nas tabelas dos localizadores que estão próximos desse enxame. 

O esquema apresentado considera que L já faz parte da rede de localizadores, ou seja, que ele já sabe 
como entrar em contato com alguns outros localizadores. Essa suposição é verdadeira para instalações 
de localizadores que tenham sido executadas anteriormente, pois eles devem salvar informações sobre 
outros localizadores, mesmo entre diferentes execuções. Se um enxame usa um rastreador, seus mem- 
bros são capazes de contar aos seus localizadores sobre outros localizadores (em uma inversão dos 
papéis de membro e localizador), pois o protocolo de membro BitTorrent foi estendido para dar suporte 
à troca de informações de contato de localizadores. Mas como um localizador recém-instalado pode 
descobrir outros localizadores? Os arquivos .torrent para enxames sem rastreador incluem informações 
de contato de um ou alguns localizadores, ao invés do URL de um rastreador, especificamente para 
essa situação. 

Um aspecto incomum do BitTorrent é que ele enfrenta diretamente o problema de justiça, ou “cida- 
dania na rede”. Muitos protocolos constantemente dependem do bom comportamento dos membros 
individuais sem serem capazes de forçar tal comportamento. Por exemplo, um nó Ethernet inescrupuloso 
poderia conseguir melhor desempenho usando um algoritmo de recuo que seja mais agressivo do que 
o recuo exponencial, ou um membro TCP inescrupuloso poderia obter melhor desempenho não coo- 
perando no controle de congestionamento. 

O bom comportamento do qual o BitTorrent depende são membros fazendo upload de pedaços para 
outros membros. Como o usuário típico do BitTorrent só deseja obter o arquivo o mais rápido possível, 
existe a tentação de implementar um membro que tenta obter todos os pedaços enquanto faz o mínimo 
de upload possível — esse é um mau membro. Para desencorajar o mau comportamento, o protocolo 
BitTorrent inclui mecanismos que permitem aos membros recompensarem ou punirem uns aos outros. 
Se um membro estiver se comportando mal, não fazendo o upload como esperado para outro membro, 
o segundo membro pode sufocar (choke) o membro mau comportado: ele pode decidir deixar de fazer o 
upload para o membro mau comportado, pelo menos temporariamente, e enviar-lhe uma mensagem 
dizendo isso. Há também um tipo de mensagem para dizer a um membro que ele deixou de ser sufocado. 
O mecanismo de sufocação também é usado por um membro para limitar o número de suas conexões 
BitTorrent ativas, para manter um bom desempenho do TCP Existem muitos algoritmos de sufocação 
possíveis, e a criação de um bom algoritmo é uma arte. 
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9.4.3 Redes de distribuição de conteúdo 


Já vimos como o HTTP executando em cima do TCP permite que os navegadores Web obtenham páginas 
de servidores Web. Porém, qualquer um que tenha esperado uma eternidade para ver uma página Web 
sabe que o sistema está longe de ser perfeito. Considerando que o backbone da Internet agora é cons- 
tituído de enlaces OC-192 (10 Gbps), não é óbvio por que isso deveria acontecer. Geralmente se concorda 
que, quando se trata de baixar páginas Web, existem quatro gargalos em potencial no sistema: 


e Aprimeira milha. A Internet pode ter enlaces de alta capacidade, mas isso não o ajuda a obter 
uma página Web mais rapidamente se você estiver conectado por um modem de 56 Kbps ou por 
um enlace sem fios 3G com baixo desempenho. 

e A última milha. O enlace que conecta o servidor à Internet, junto com o próprio servidor, podem 
estar sobrecarregados por muitas solicitações, mesmo que a largura de banda agregada desse 
enlace seja muito alta. 

e O próprio servidor. Um servidor tem uma quantidade finita de recursos (CPU, memória, largura 
de banda de disco etc.) e pode ser sobrecarregado por muitas solicitações simultâneas. 

e Pontos de troca de tráfego. Alguns dos provedores de serviços da Internet que implementam 
coletivamente o backbone da Internet podem ter enlaces internos com elevada largura de banda, 
mas têm pouca motivação para oferecer conectividade de alta capacidade aos seus pares. Se você 
estiver conectado ao provedor A e o servidor estiver conectado ao provedor B, então a página que 
você solicita pode ser descartada no ponto em que A e B trocam tráfego. 


Não há muita coisa que alguém além de você possa fazer sobre o primeiro problema, mas é possível 
usar replicação para resolver os problemas restantes. Um sistema que faz isso normalmente é consi- 
derado uma rede de distribuição de conteúdo (CDN - Content Distribution Network). A Akamai opera 
aquela que é provavelmente a CDN mais conhecida. 

Aideia de uma CDN é distribuir geograficamente uma coleção de servidores substitutos, que mantêm 
em cache páginas normalmente mantidas em algum conjunto de servidores de back-end. Assim, ao 
invés de ter milhões de usuários esperando uma eternidade para acessar www.cnn.com quando surge 
uma notícia muito importante — essa situação é conhecida como flash crowd (“multidão repentina”) —, 
é possível distribuir essa carga por muitos servidores. Além disso, ao invés de ter de atravessar vários 
provedores para alcançar www.cnn.com, se esses servidores substitutos estiverem espalhados por 
todos os provedores de backbone, então deve ser possível alcançar um deles sem ter que atravessar um 
ponto de troca de tráfego. Naturalmente, a manutenção de milhares de servidores substitutos por toda 
a Internet também é muito dispendiosa para ser feita por qualquer site sozinho que queira oferecer 
um acesso melhor às suas páginas Web. As CDNs comerciais oferecem esse serviço para muitos sites, 
amortizando seu custo pelos vários clientes. 

Embora os chamemos de servidores substitutos, na verdade, estes também podem ser vistos correta- 
mente como caches. Se eles não tiverem uma página que foi solicitada por um cliente, eles a pedem no 
servidor de back-end. Porém, na prática, os servidores de back-end replicam seus dados proativamente 
pelos substitutos, em vez de esperar que eles sejam solicitados sob demanda. Também acontece que 
somente páginas estáticas, e não de conteúdo dinâmico, são distribuídas pelos substitutos. Os clientes 
precisam ir até o servidor de back-end para obter qualquer conteúdo que mude com frequência (por 
exemplo, resultados de jogos e cotações de ações) ou que seja produzido como resultado de alguma 
computação (por exemplo, uma consulta a um banco de dados). 

Ter um grande conjunto de servidores distribuídos geograficamente não resolve totalmente o proble- 
ma. Para completar esse quadro, as CDNs também precisam oferecer um conjunto de redirecionadores, 
que encaminham solicitações do cliente ao servidor mais apropriado, como mostra a Figura 9.30. O 
objetivo principal dos redirecionadores é selecionar o servidor para cada solicitação que resulte no me- 
lhor tempo de resposta para o cliente. Um objetivo secundário é que o sistema como um todo processe 
tantas solicitações por segundo quanto o hardware subjacente (enlaces de rede e servidores Web) possa 
admitir. O número médio de solicitações que podem ser satisfeitas em determinado período de tempo 
-algo conhecido como vazão do sistema — é principalmente uma questão de quando o sistema está sob 


480 REDES DE COMPUTADORES ELSEVIER 














aaa.com bbb.com ccc.com 
Es E = Servidores 
de back-end 
[Cache 
=~ _ — 














Redirecionadores 


J [J 
GOO 








Clientes 


Servidores 
substitutos 
espalhados 
geograficamente 


FIGURA 9.30 Componentes em uma rede de distribuição de conteúdo (CDN). 


carga intensa, como, por exemplo, quando uma “flash crowd” está acessando um pequeno conjunto 
de páginas ou um ataque de negação de serviço distribuído (DDos - Distributed Denial of Service) 
está sendo realizado contra determinado site, como aconteceu com CNN, Yahoo e vários outros sites 
importantes em fevereiro de 2000. 

As CDNSs utilizam diversos fatores para decidir como distribuir as solicitações do cliente. Por exemplo, 
para diminuir o tempo de resposta, um redirecionador poderia selecionar um servidor com base em 
sua proximidade da rede. Por outro lado, para melhorar a vazão geral do sistema, é desejável balancear 
a carga uniformemente por um conjunto de servidores. Tanto a vazão quanto o tempo de resposta são 
melhorados se o mecanismo de distribuição levar em consideração a localidade, ou seja, selecionar um 
servidor que provavelmente já tenha a página sendo solicitada em seu cache. A combinação exata de 
fatores que devem ser empregados por uma CDN está aberta a debates. Esta seção considera algumas 
das possibilidades. 


Mecanismos 

Conforme descrevemos até aqui, um redirecionador é apenas uma função abstrata, embora pareça 
algo que um roteador poderia ser solicitado a fazer, pois ele encaminha logicamente uma mensagem 
de solicitação de modo semelhante a como um roteador encaminha pacotes. Na verdade, existem 
vários mecanismos que podem ser usados para implementar o redirecionamento. Observe que, para a 
finalidade desta discussão, consideramos que cada redirecionador conhece o endereço de cada servidor 
disponível. (Daqui por diante, deixamos de lado o qualificador “substituto” e falamos simplesmente em 
termos de um conjunto de servidores.) Na prática, alguma forma de comunicação externa ocorre para 
manter essa informação atualizada à medida que servidores são adicionados ou removidos. 

Primeiro, o redirecionamento poderia ser implementado expandindo-se o DNS para retornar 
diferentes endereços de servidor aos clientes. Por exemplo, quando um cliente solicitar a tradução do 
nome www.cnn.com, o servidor de DNS poderia retornar o endereço IP de um servidor hospedando as 
páginas Web da CNN e que tenha a menor carga. Como alternativa, para determinado conjunto de 
servidores, ele poderia simplesmente retornar endereços em uma forma de rodízio. Observe que a 
granularidade do redirecionamento baseado em DNS normalmente está no nível de um site (por 
exemplo, cnn.com) em vez de um URL específico (por exemplo, http:/Avww.cnn.com/2002/WORLD/ 
europe/06/21 /william.birthday/index.html). Porém, ao retornar um link embutido, o servidor pode 
reescrever o URL, efetivamente levando o cliente para o servidor mais apropriado para esse objeto 
específico. 





Capítulo 9º Aplicações 481 
i 
ELSEVIER 


CDNs comerciais basicamente utilizam uma combinação de reescrita de URL e redirecionamento 
baseado em DNS. Por motivos de escalabilidade, o servidor de DNS de alto nível aponta para um 
servidor de DNS de nível regional, que então responde com o endereço do servidor. Para responder 
a mudanças rapidamente, os servidores de DNS modificam o TTL dos registros de recursos que eles 
retornam para um período muito curto, como 20 segundos. Isso é necessário para que os clientes não 
mantenham resultados em cache, e assim deixem de retornar ao servidor de DNS para o mapeamento 
URL-servidor mais recente. 

Outra possibilidade é usar o recurso de redirecionamento do HTTP: o cliente envia uma mensagem 
de solicitação a um servidor, que responde indicando um novo servidor (melhor), o qual o cliente 
deverá contatar para obter a página. Infelizmente, o redirecionamento baseado em servidor resulta 
em um tempo de ida e volta adicional na Internet e, pior ainda, os servidores podem ficar vulneráveis 
a sobrecarga devido à própria tarefa de redirecionamento. Em vez disso, se houver um nó próximo 
do cliente (por exemplo, um proxy Web local) que saiba quais são os servidores disponíveis, então ele 
poderá interceptar a mensagem de solicitação e instruir o cliente a solicitar a página de um servidor 
apropriado. Nesse caso, ou o redirecionador teria de estar em um ponto de estrangulamento da rede, 
de modo que todas as solicitações saindo do cliente passassem por ele, ou o cliente teria de cooperar, 
endereçando o proxy explicitamente (como em um proxy clássico, em vez de um transparente). 

Neste ponto, você pode estar perguntando o que as CDNs têm a ver com as redes overlay, e embora 
ver uma CDN como uma rede overlay seja um pouco exagerado, elas possuem uma característica muito 
importante em comum. Assim como um nó overlay, um redirecionador baseado em proxy toma uma 
decisão de roteamento no nível da aplicação. Em vez de encaminhar um pacote com base em um 
endereço e seu conhecimento da topologia da rede, ele encaminha solicitações HTTP com base em 
um URL e seu conhecimento da localização e carga de um grupo de servidores. A arquitetura atual da 
Internet não fornece suporte ao redirecionamento direto — onde “direto” significa que o cliente envia 
uma solicitação HTTP ao redirecionador, que a encaminha para o destino —, de modo que, ao invés disso, 
o redirecionamento normalmente é implementado indiretamente, com o redirecionador retornando o 
endereço de destino apropriado e o cliente contatando o servidor ele próprio. 


Políticas 

Agora, vamos considerar alguns exemplos de políticas que os redirecionadores poderiam usar para 
encaminhar solicitações. Na realidade, já sugerimos uma política simples — o rodízio. Um esquema 
semelhante seria simplesmente selecionar um dos servidores disponíveis aleatoriamente. Essas duas 
abordagens realizam um bom trabalho por espalharem a carga uniformemente pela CDN, mas não 
realizam um trabalho particularmente bom reduzindo o tempo de resposta percebido pelo cliente. 

É óbvio que nenhum desses dois esquemas leva em consideração a proximidade da rede; porém, 
tão importante quanto isso, eles também ignoram a localidade. Ou seja, as solicitações para o mes- 
mo URI são encaminhadas para servidores diferentes, tornando menos provável que a página seja 
atendida pelo cache na memória do servidor selecionado. Isso força o servidor a obter a página do 
seu disco e, possivelmente, até mesmo do servidor de back-end. Mas como um conjunto distribuído de 
redirecionadores poderia fazer com que solicitações para a mesma página sigam para o mesmo 
servidor (ou pequeno conjunto de servidores), sem que haja uma coordenação global? A resposta é 
surpreendentemente simples: todos os redirecionadores utilizam alguma forma de mecanismo de hash 
para mapear os URLs de forma determinística a uma pequena faixa de valores. O benefício principal 
dessa técnica é que nenhuma comunicação entre redirecionadores é necessária para se conseguir a 
operação coordenada; não importa qual redirecionador receba um URL, o processo de hash produz 
a mesma saída. 

Logo, de que é composto um bom esquema de cálculo de hash? O esquema clássico de cálculo de 
hash usando módulo - que calcula o hash de cada URL módulo o número de servidores — não é adequado 
para esse ambiente. Isso porque, se o número de servidores mudar, o cálculo do módulo resultará em 
uma fração diminuta das páginas mantendo o mesmo servidor atribuído a elas. Embora não esperemos 
mudanças frequentes no conjunto de servidores, o fato de que o acréscimo de novos servidores no 
conjunto causará uma reatribuição maciça é indesejável. 
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Uma alternativa é usar o mesmo algoritmo de hash coerente discutido na Seção 9.4.2. Especificamente, 
cada redirecionador primeiro dispõe cada servidor no círculo unitário. Depois, para cada URL que 
chega, o redirecionador também transforma o URL em um valor no círculo unitário, e o URL é atribuí- 
do ao servidor que se encontra mais próximo do seu valor de hash no círculo. Se um nó falhar nesse 
esquema, sua carga passa para seus vizinhos (no círculo unitário), de modo que o acréscimo /remoção 
de um servidor só causa mudanças locais nas atribuições de tratamento de solicitações. Observe que, 
ao contrário do caso peer-to-peer, onde uma mensagem é roteada de um nó para outro com o objetivo 
de encontrar o servidor cujo identificador seja o mais próximo dos objetos, cada redirecionador sabe 
como o conjunto de servidores é mapeado no círculo unitário, de modo que cada um pode selecionar 
independentemente o servidor “mais próximo”. 

Essa estratégia pode ser facilmente estendida para levar em consideração a carga do servidor. Supo- 
nha que o redirecionador conheça a carga atual de cada um dos servidores disponíveis. Essa informação 
pode não estar perfeitamente atualizada, mas podemos imaginar o redirecionador simplesmente 
contando quantas vezes encaminhou uma solicitação a cada servidor durante os últimos segundos, 
e usando essa contagem como uma estimativa da carga atual desse servidor. Ao receber um URL, o 
redirecionador calcula o hash do URL e de cada um dos servidores disponíveis, ordenando os valores 
resultantes. Essa lista ordenada efetivamente define a sequência em que o redirecionador considerará 
os servidores disponíveis. O redirecionador, então, percorre essa lista até encontrar um servidor cuja 
carga esteja abaixo de algum limite. O benefício dessa técnica em comparação com o hash coerente 
simples é que a ordem de servidores é diferente para cada URL, de modo que, se um servidor falhar, sua 
carga é distribuída uniformemente entre as outras máquinas. Essa técnica é a base para o Protocolo de 
Roteamento para Matriz de Caches (CARP — Cache Array Routing Protocol), mostrado no pseudocódigo 
a seguir. 


SelecionaServidor(URL, S) 

para cada servidor s; no conjunto de servidores § 
peso;=hash(URL, endereço(s;)) 

classifica peso 

para cada servidor s; em ordem decrescente de peso; 
se Carga(s;) < limite então 

retorna s; 
retorna servidor com maior peso 


Quando a carga aumenta, esse esquema deixa de usar apenas o primeiro servidor na lista ordenada 
e passa a distribuir as solicitações por vários servidores. Algumas páginas normalmente atendidas por 
servidores “ocupados” também começarão a ser atendidas por servidores menos ocupados. Como esse 
processo é baseado na carga agregada do servidor, e não na popularidade das páginas individuais, os 
servidores hospedando algumas páginas populares podem encontrar mais servidores compartilhando 
sua carga do que aqueles hospedando páginas coletivamente impopulares. No processo, algumas 
páginas impopulares serão replicadas no sistema simplesmente porque são hospedadas principalmente 
em servidores ocupados. Ao mesmo tempo, se algumas páginas se tornarem extremamente populares, 
é concebível que todos os servidores no sistema possam ser responsáveis por atendê-las. 

Finalmente, é possível introduzir a proximidade da rede na equação, pelo menos de duas maneiras 
diferentes. A primeira é diminuir a distinção entre carga de servidor e proximidade da rede, monitorando 
o tempo gasto por um servidor para responder às solicitações e usando essa medição, no algoritmo 
anterior, como um parâmetro de “carga do servidor”. Essa estratégia costuma preferir servidores 
próximos e pouco carregados a servidores distantes e bastante carregados. Uma segunda técnica é 
contemplar a proximidade em um estágio mais cedo da decisão, limitando o conjunto de servidores 
candidatos considerados pelo algoritmo anterior (S) a somente aqueles que estejam próximos. O pro- 
blema mais difícil é decidir quais dos muitos servidores em potencial estão adequadamente próximos. 
Uma solução seria selecionar apenas os servidores que estão disponíveis no mesmo provedor do cliente. 
Uma solução ligeiramente mais sofisticada seria examinar o mapa de sistemas autônomos produzido 
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pelo BGP e selecionar como candidatos apenas os servidores dentro de algum número de saltos a partir 


do cliente. Achar o equilíbrio certo entre proximidade de rede e localidade do cache do servidor é um 
assunto de constante pesquisa. 


9.5 Resumo 


Vimos dois dos mais utilizados protocolos de aplicação baseados no paradigma cliente/servidor: 
SMTP usado para a troca de correio eletrônico (e-mail), e HTTP usado para navegar pela World Wide 
Web. Vimos como a comunicação entre aplicações está motivando a criação de novos arcabouços de 
desenvolvimento de protocolo, como SOAP e REST. E examinamos os protocolos de controle de sessão, 
como SIP e H.323, que são usados para controlar aplicações multimídia, como Voz sobre IP Além desses 
protocolos de aplicação, vimos alguns protocolos de suporte críticos: o protocolo DNS usado pelo 
Sistema de Nomes de Domínio (Domain Naming System) e o SNMP usado para consultar nós remotos 
para fins de gerenciamento de rede. Finalmente, examinamos aplicações emergentes — incluindo 
overlay, peer-to-peer e redes de distribuição de conteúdo — que misturam processamento de aplicações 
e encaminhamento de pacotes de maneiras inovadoras. 

Os protocolos de aplicação são um tipo curioso. De muitas maneiras, aplicações cliente/servidor 
tradicionais são como outra camada de protocolo de transporte, exceto por terem internamente um 
conhecimento específico da aplicação. Você poderia argumentar que eles são apenas protocolos de 
transporte especializados, e que os protocolos de transporte são colocados um em cima do outro até 
produzirem o serviço exato necessário pela aplicação. De modo semelhante, os protocolos de overlay 
e peer-to-peer podem ser vistos como oferecendo uma infraestrutura de roteamento alternativa, mas, 
novamente, que está moldada para as necessidades da aplicação específica. Uma lição segura que retira- 
mos dessa observação é que o projeto de protocolos no nível de aplicação realmente não é diferente do 
projeto dos protocolos básicos da rede, e que quanto mais entendemos a respeito do segundo, melhor 
será o projeto do primeiro. Observe também que o enfoque de sistemas — conhecer como funções e 
componentes interagem para criar um sistema completo - se aplica, pelo menos, tanto no projeto de 
aplicações quanto em qualquer outro aspecto das redes. 


E E O que vem em seguida: nova arquitetura de rede m 


É difícil dar a última palavra a respeito de uma questão específica no domínio dos protocolos de 
aplicação — o campo inteiro está aberto posto que que novas aplicações são inventadas diariamente 
e as necessidades de rede dessas aplicações são, digamos assim, dependentes da aplicação. O desafio 
real para os projetistas de rede é reconhecer que o que as aplicações precisam da rede muda com o 
tempo, e essas mudanças controlam os protocolos de transporte que desenvolvemos e a funciona- 
lidade que colocamos nos roteadores da rede. 

O desenvolvimento de novos protocolos de transporte é um problema razoavelmente tratável. 
Você pode não conseguir fazer com que a IETF consagre seu protocolo de transporte como sendo tão 
importante quanto o TCP ou o UDP mas certamente nada o impedirá de projetar a melhor aplicação 
de multimídia do mundo, que venha junto com um novo protocolo fim a fim, que trabalha em cima 
do UDP semelhante ao que acontece com o RTP 

Por outro lado, empurrar conhecimento específico da aplicação para o meio da rede — para os 
roteadores — é um problema muito mais difícil. Isso porque, para afetar determinada aplicação, 
qualquer novo serviço ou funcionalidade da rede pode ter de ser carregado em muitos dos (se não 
todos os) roteadores na Internet. As redes overlay oferecem um meio de introduzir nova funciona- 
lidade à rede sem a cooperação de todos os (ou mesmo algum dos) roteadores; porém, em longo 
prazo, podemos esperar que a arquitetura da rede subjacente tenha de mudar para acomodar esses 
overlays. Vimos essa questão com a RON - como a RON e a seleção de rota do BGP interagem entre 
si — e podemos esperar que essa se torne uma questão geral quando as redes de overlay se tornarem 
mais predominantes. 
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Uma possibilidade é de que uma arquitetura alternativa fixa não se desenvolva, mas, ao invés 
disso, a próxima arquitetura de rede seja altamente adaptável. No limite, ao invés de definir uma in- 
fraestrutura para transportar pacotes de dados, a arquitetura da rede poderia permitir que os pacotes 
transportem dados e código (e possivelmente ponteiros para códigos), que digam aos roteadores 
como eles devem processar o pacote. Esse tipo de rede levanta uma série de questões, sendo que não 
menos importante é a questão de como impor a segurança em um mundo onde aplicações quaisquer 
podem efetivamente programar os roteadores. Outra possibilidade é que a virtualização das redes 
se torne a norma, talvez com algumas “fatias” oferecendo serviços robustos, bem compreendidos e 
totalmente depurados, enquanto outras são usadas para funções mais experimentais. Essa é uma 
tendência que a comunidade de pesquisa atualmente está buscando. 
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Berners-Lee, T.; Caillia, R.; Luotonen, A.; Nielsen, H.; Secret, A. The World-Wide Web. Communications of the ACM, v. 37, 
n.8, p. 76-82, agosto de 1994. 

Mockapetris, P; Dunlap, K. Development of the domain name system. Proceedings of the SIGCOMM '88 Symposium, 
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O SMTP foi definido originalmente na RFC 821 [Pos82] e, naturalmente, a RFC 822 é a REC 822 [Cro82]. 
Elas se tornaram, na terminologia do IETF “obsoletas” pelas publicações [Kle01] e [Res01], respecti- 
vamente. O MIME é definido em uma série de RFCs; a versão mais recente está definida na RFC 2045 
[FB96], com várias RFCs adicionais preenchendo os detalhes. 

Aversão 1.0 do HTTP é especificada na REC 1945 [BLFF96], e a versão mais recente (1.1) está definida 
na RFC 2616 [FGM*99]. Mogul [Mog95] defende o uso das conexões persistentes no HTTP 1.1. Existem 
inúmeros artigos escritos sobre desempenho da Web, especialmente o mecanismo de cache da Web. 
Um bom exemplo é um artigo de Danzig sobre o tráfego na Web e suas implicações sobre a eficácia 
do mecanismo de cache [Dan98]. A tese de doutorado de Roy Fielding [Fie00] é a referência definitiva 
para o REST. 

O SIP é definido na RFC 3261 [SCJ+02], que contém uma seção de tutorial útil e também a especi- 
ficação detalhada do protocolo. Assim como o MIME, existem muitas outras RFCs que estendem o 
protocolo. 

Existe uma grande variedade de artigos sobre nomeação, bem como a questão relacionada da 
descoberta de recursos (descobrir quais recursos existem em primeiro lugar). Estudos gerais sobre 
nomeação podem ser encontrados em Terry [Ter86], Comer e Peterson [CP89], Birrell et al. [BLNS82], 
Saltzer [Sal78], Shoch [Sho78] e Watson [Wat81]; os sistemas de nomes baseados em atributos (des- 
critivos) são descritos em Peterson [Pet88] e Bowman et al. [BPY90]; e a descoberta de recursos é o 
assunto de Bowman et al. [BDMS94]. 
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O gerenciamento de redes é um campo suficientemente grande e importante para que a IETF dedique 
uma área inteira para ele. Há mais de 100 RFCs descrevendo os diversos aspectos do SNMP e das MIBs. 
Porém, as duas referências principais são a RFC 2578 [MPS99], que define a estrutura das informações 
de gerenciamento para a versão 2 do SNMP (SNMPv2), e a RFC 3416 [Pre02], que define as operações de 
protocolo para o SNMPv2. Muitas das outras RFCs relacionadas a SNMP/MIB definem extensões ao 
conjunto básico de variáveis MIB — por exemplo, variáveis que são específicas a uma tecnologia de rede 
em particular ou ao produto de um vendedor em particular. Perkins et al. [PM97] oferecem uma boa 
introdução ao SNMP e às MIBs. 

O relatório do National Research Council sobre a ossificação da Internet pode ser encontrado em 
[NRC01], e uma proposta para usar redes overlay a fim de introduzir uma tecnologia que possa causar 
perturbações na rede foi feita por Peterson, Anderson, Culler e Roscoe [PACRO2]. O argumento original 
para redefinir rotas BGP foi feito por Savage, Collins, Hoffman, Snell e Anderson [SCH*+99]. A ideia de 
usar DNS para balanceamento de carga de um conjunto de servidores é descrito na RFC 1794 [Bri95]. 
Um tratamento abrangente da questão de fazer cache na Web versus usar servidores replicados pode 
ser encontrado no livro de Rabinovich e Spatscheck [RS02]. Wang, Pai e Peterson exploram o espaço de 
projeto para redirecionadores [WPP02]. 

Finalmente, recomendamos a seguinte referência viva para ajudá-lo a acompanhar a rápida evolução 
da Web e para uma grande riqueza de informações relacionadas aos padrões e história relacionados à 
Web: 

e http://www.w3.org/: World Wide Web Consortium. 


Exercícios 


1. Discuta como você poderia reescrever o SMTP ou o HTTP para utilizar um protocolo hipotético 
de solicitação/resposta de uso geral. Algum equivalente apropriado das conexões persistentes 
poderia ser movido da camada de aplicação para tal protocolo de transporte? Que outras tarefas 
da aplicação poderiam ser movidas para esse protocolo? 

2. A maioria dos clientes Telnet pode ser usada para conectar-se à porta 25, que é a porta SMTP, 
ao invés da porta Telnet. Usando tal ferramenta, conecte-se a um servidor SMTP e envie 
para si mesmo (ou para alguém mais, com permissão) alguma mensagem de e-mail forjada. 
Depois, examine os cabeçalhos para procurar alguma evidência de que a mensagem não é 
genuína. 

3. Que recursos poderiam ser usados pelo (ou acrescentados ao) SMTP e/ou daemon de correio, 
como sendmail, para oferecer alguma resistência à falsificação de e-mails, como a realizada 
no exercício anterior? 

4. Descubra como os hosts SMTP tratam comandos desconhecidos vindos do outro lado e, em particular, 
como esse mecanismo permite a evolução do protocolo (por exemplo, para um “SMTP estendido”). 
Você pode ler a RFC ou contatar um servidor SMTP como no Exercício 2, e testar suas respostas 
com comandos inexistentes. 

5. Conforme apresentamos no texto, o SMTP envolve a troca de várias mensagens pequenas. 

Na maioria das vezes, as respostas do servidor não afetam o que o cliente envia mais tarde. 

O cliente, assim, poderia implementar uma canalização de comandos: enviar vários comandos 

em uma única mensagem. 

a. Para que comandos SMTP o cliente precisa prestar atenção às respostas do servidor? 

b. Suponha que o servidor leia cada mensagem do cliente com um comando gets() ou 
equivalente, que lê uma cadeia de caracteres até encontrar um <LF >. O que ele teria de fazer 
para detectar que um cliente usou essa canalização de comandos? 

c. Apesar disso, sabe-se que a canalização não funciona com alguns servidores; descubra 
como um cliente pode negociar seu uso. 

6. Um dos problemas centrais enfrentados por um protocolo como o MIME é a grande quantidade 
de formatos de dados disponíveis. Consulte a RFC do MIME para descobrir como o MIME lida 
com formatos de imagem e texto novos ou específicos do sistema. 


486 REDES DE COMPUTADORES ELSEVIER 


10. 


11. 


12. 


13. 


14. 


15. 


16. 


17. 


18. 


O MIME admite diversas representações do mesmo conteúdo, usando a sintaxe multipart/ 

alternative; por exemplo, o texto poderia ser enviado como text/plain, text/richtext e 

application/postscript. Em sua opinião, por que o texto simples é admitido como sendo o 

primeiro formato, embora as implementações poderiam achar mais fácil colocar o texto simples 

após seu formato nativo? 

Consulte a RFC do MIME para descobrir como a codificação base64 lida com dados binários 

com um tamanho não divisível por três bytes. 

O Post Office Protocol (POP3) permite apenas que um cliente obtenha a mensagem de correio 

eletrônico, usando uma senha para autenticação. Tradicionalmente, para enviar uma mensagem 

de e-mail, um cliente simplesmente a enviaria para seu servidor (usando SMTP) e esperaria que 

ela fosse repassada. 

a. Explique por que os servidores de correio eletrônico não permitem mais o repasse a partir 
de clientes quaisquer. 

b. Proponha uma opção no SMTP para fazer a autenticação remota de clientes. 

c. Descubra que métodos existentes estão disponíveis para resolver essa questão. 

No HTTP versão 1.0, um servidor marcava o final de uma transferência por meio do fechamento 

da conexão. Explique por que, em termos da camada TCP isso era um problema para os 

servidores. Descubra como o HTTP versão 1.1 evita isso. Como um protocolo de solicitação / 

resposta de uso geral resolve isso? 

Descubra como configurar um servidor HTTP a fim de eliminar a mensagem 404 not found 

e retornar uma mensagem padrão (e mais amigável) em seu lugar. Decida se esse recurso faz 

parte do protocolo ou de uma implementação, ou se é tecnicamente permitido pelo protocolo. 

(A documentação para o servidor HTTP apache pode ser encontrada em www.apache.org.) 

Por que o comando GET do HTTP na Seção 9.1.2, 


GET http://www.cs.princeton.edu/index.html HTTP/1.1 


contém o nome do servidor sendo contatado? O servidor já não conheceria seu nome? 

Use Telnet, como no Exercício 2, para conectar-se à porta 80 de um servidor HTTP e descubra 

o que acontece se você omitir o nome do host. 

Quando um servidor HTTP inicia um close() na sua extremidade de uma conexão, ele precisa 
esperar no estado TCP FIN WAIT 2 para que o cliente feche a outra extremidade. Que 
mecanismo dentro do protocolo TCP poderia ajudar um servidor HTTP a lidar com clientes não 
cooperativos ou mal implementados, que não fecham a partir de sua extremidade? Se possível, 
descubra a respeito da interface de programação para esse mecanismo e indique como um 
servidor HTTP poderia utilizá-la. 

Suponha que um site Web muito grande queira um mecanismo pelo qual os clientes acessem um 
dos diversos servidores HTTP o que estiver “mais próximo”, segundo alguma métrica adequada. 
a. Discuta o desenvolvimento de um mecanismo dentro do HTTP para fazer isso. 

b. Discuta o desenvolvimento de um mecanismo dentro do DNS para fazer isso. 

Compare os dois. Alguma dessas técnicas poderia funcionar sem a atualização do navegador? 
Protocolos de aplicação como FTP e SMTP foram projetados do zero, e parecem funcionar 
razoavelmente bem. Que característica dos protocolos do tipo “Business to Business” (para 
negócios entre empresas) e “Enterprise Application Integration” (Integração de Aplicações 
Empresariais) faz com que eles exijam um arcabouço de protocolos de Web Services? 

Escolha um Web Service com interfaces equivalentes a REST e SOAP como aqueles oferecidos 
pela Amazon.com. Compare como operações equivalentes são implementadas nos dois estilos. 
Obtenha a WSDL para algum Web Service no estilo SOAP e escolha uma operação. Nas 
mensagens que implementam essa operação, identifique os campos. 

Suponha que alguns destinatários em uma grande conferência possam receber dados 

em uma largura de banda muito mais alta do que outros. Que tipos de coisas poderiam ser 
implementadas para considerar isso? (Dica: Considere tanto o Session Announcement Protocol 
(SAP) quanto a possibilidade de utilizar “mixers” de terceiros.) 
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19. Como você poderia codificar os dados de áudio (ou vídeo) em dois pacotes, de modo que, 
se um pacote for perdido, então a resolução seja simplesmente reduzida ao que seria esperado 
com metade da largura de banda? Explique por que isso é muito mais difícil se a codificação 
tipo JPEG for utilizada. 

20. Explique o relacionamento entre localizadores de recursos uniformes (URLs) e identificadores 
de recursos uniformes (URIs). Dê um exemplo de um URI que não seja um URL. 

21. Descubra que outros recursos os registros MX do DNS oferecem além de fornecer um apelido 
para um servidor de correio; afinal, isso poderia ser fornecido por um registro CNAME do DNS. 
Os registros MX existem para dar suporte ao correio eletrônico; um registro WEB semelhante 
teria alguma utilidade no suporte para o HTTP? 

22. ARPe DNS dependem de caches; os tempos de vida da entrada de cache no ARP normalmente 
são de 10 minutos, enquanto o cache do DNS é da ordem de dias. Justifique essa diferença. 
Que consequências indesejáveis poderiam existir por haver um tempo de vida tão longo 
para a entrada de cache do DNS? 

23. Asimples existência do IPv6 simplifica o ARP ao permitir que endereços de hardware façam 
parte do endereço IPv6. Como isso complica a tarefa do DNS? Como isso afeta o problema de 
localizar seu servidor de DNS local? 

24. Os servidores de DNS também permitem a pesquisa reversa; dado um endereço IP 128.112.169.4, 
ele é convertido para uma cadeia de caracteres de texto 4.169.112.128.in-addr.arpa e buscado 
por meio de registros PTR no DNS (que formam uma hierarquia de domínios semelhante à 
hierarquia de domínios de endereços). Suponha que você queira autenticar a origem de um 
pacote com base em seu nome de host e esteja confiante de que o endereço IP de origem é 
genuíno. Explique a insegurança na conversão do endereço de origem para um nome, como 
acima, e depois na comparação desse nome com determinada lista de hosts confiáveis. (Dica: 
Você estaria confiando nos servidores de DNS de quem?) 

25. Qual é o relacionamento entre um nome de domínio (por exemplo, cs.princeton.edu) e um 
número de sub-rede IP (por exemplo, 192.12.69.0)? Todos os hosts na sub-rede precisam ser 
identificados pelo mesmo servidor de nomes? E quanto à pesquisa reversa, como no exercício 
anterior? 

26. Suponha que um host decida usar um servidor de nomes que não se encontra dentro de sua 
organização para realizar a tradução de endereços. Quando isso não resultaria em mais tráfego 
total, para consultas não encontradas em qualquer cache de DNS, do que com um servidor 
de nomes local? Quando isso poderia resultar em uma melhor taxa de acertos do cache de DNS e 
possivelmente menos tráfego total? 

27. A Figura 9.17 mostra a hierarquia de servidores de nomes. Como você representaria essa 
hierarquia se um servidor de nomes atendesse a várias zonas? Nesse ambiente, como a 
hierarquia de servidor de nomes se relaciona com a hierarquia de zonas? Como você lida com o 
fato de que cada zona pode ter vários servidores de nomes? 

28. Use o utilitário/serviço whois para descobrir quem está encarregado do seu site, pelo menos 
no que diz respeito ao InterNIC. Pesquise seu site tanto por nome de DNS quanto por número 
de rede IP; para o segundo caso, você pode ter que tentar um servidor whois alternativo 
(por exemplo, whois-h whois.arin.net...). Teste também princeton.edu e cisco.com. 

29. Muitas organizações menores possuem seus sites Web mantidos por terceiros. Como você 
poderia usar o whois para descobrir se isso acontece e, se acontecer, a identidade desse terceiro? 

30. Uma característica da hierarquia de DNS .com existente é que ela é extremamente ampla. 

a. Proponha uma reorganização mais hierárquica da hierarquia .com. Que objeções você 
poderia prever para a adoção de sua proposta? 

b. Quais seriam algumas das consequências de ter a maioria dos nomes de domínio do DNS 
com quatro ou mais níveis, contra os dois presentes nos muitos nomes existentes? 

31. Suponha, por outro lado, que abandonemos qualquer pretensão da hierarquia do DNS e 
simplesmente passemos todas as entradas .com para o servidor de nomes raiz: www.cisco.com 
se tornaria www.cisco, ou talvez apenas cisco. Como isso afetaria o tráfego geral do servidor 
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32. 


33. 


34. 


de nomes raiz Como isso afetaria tal tráfego para o caso específico de tradução de um nome 
como cisco em um endereço de servidor Web? 

Que problemas no cache de DNS aparecem quando mudamos o endereço IP digamos, do nome 
de host de um servidor Web? Como eles poderiam ser minimizados? 

Use um utilitário de pesquisa de DNS conveniente (por exemplo, dig) e desative o recurso 

de pesquisa recursiva (por exemplo, com +norecurse), de modo que, quando seu utilitário 
enviar uma consulta a um servidor de DNS, e esse servidor não puder responder totalmente 

à solicitação com seus próprios registros, o servidor responda com o próximo servidor de 

DNS na sequência de busca, em vez de encaminhar a consulta automaticamente ao próximo 
servidor. Depois execute manualmente uma busca de nomes, como aquela na Figura 9.18; 
experimente o nome de host www.cs.princeton.edu. Liste cada servidor de nomes intermediário 
que é contatado. Você também pode ter que especificar que as consultas são para registros NS, 
ao invés de registros A normais. 

Descubra se existe à sua disposição um nó SNMP que responda consultas que você lhe envie. 
Se houver, localize alguns utilitários de SNMP (por exemplo, o pacote ucd-snmp) e experimente 
o seguinte: 

a. Obtenha o grupo system inteiro, usando algo como 


snmpwalk nomenó public system 


35 


36. 


37. 


38. 


39, 


40. 


Experimente também o comando anterior com 1 no lugar de system. 
b. Percorra manualmente o grupo system, usando várias operações GET-NEXT do SNMP 

(por exemplo, usando snmpgetnext ou equivalente), obtendo uma entrada de cada vez. 
. Usando o dispositivo SNMP e os utilitários do exercício anterior, obtenha o grupo tcp 
(numericamente, o grupo 6) ou algum outro grupo. Depois, faça algo para alterar alguns 
dos contadores do grupo, e obtenha o grupo novamente para verificar a mudança. Tente fazer 
isso de modo que você possa ter certeza de que suas ações foram a causa da mudança registrada. 
Que informações fornecidas pelo SNMP poderiam ser úteis para alguém planejando o ataque 
de falsificação de IP do Exercício 17 do Capítulo 5º Que outras informações do SNMP poderiam 
ser consideradas sensíveis? 
Como você projetaria um mecanismo de redirecionamento para uma CDN usando apenas 
redirecionamentos HTTP 302 ou apenas o DNS? Quais são as limitações de cada método? Seria 
viável uma combinação dos dois mecanismos? 
Que problema seria encontrado por um mecanismo de redirecionamento baseado em DNS 
se ele quisesse selecionar o servidor mais apropriado com base na informação atual sobre a 
carga? 
Imagine uma situação em que existam várias CDNs e que elas queiram trocar tráfego umas 
com as outras (semelhante ao modo como os sistemas autônomos trocam tráfego uns com 
os outros na camada IP) para fins de entrega de conteúdo para um conjunto maior de usuários 
finais. Por exemplo, a CDN A poderia fornecer conteúdo em favor de um conjunto de provedores 
de conteúdo e a CDN B poderia fornecer conteúdo em favor de outro conjunto de provedores de 
conteúdo, onde A e B possuem uma cobertura física que lhes permite entregar esse conteúdo 
a conjuntos distintos de usuários finais. Esboce como as CDNSs A e B podem usar uma 
combinação de redirecionamento de DNS e redirecionamentos HTTP 302 para entregar 
conteúdo dos provedores de conteúdo da CDN A para os usuários finais da CDN B (e vice-versa). 
Imagine uma CDN configurada como uma hierarquia de cache, com os usuários finais acessando 
o conteúdo dos caches de borda, que obtêm o conteúdo em um cache pai em caso de falta 
de informação em seu próprio cache, e assim por diante até o cache raiz, que por fim obtém 
o conteúdo em um servidor de origem. Que métrica orientaria as decisões de aprovisionamento 
para (a) acrescentar mais capacidade de armazenamento em determinado cache e (b) 
acrescentar um nível adicional à hierarquia de cache. 
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41. Um overlay de multicast efetivamente empurra o fluxo de conteúdo sendo transmitido de 

uma única fonte para vários destinos, sem manter o fluxo em cache nos nós intermediários. 

Uma CDN efetivamente puxa o conteúdo (incluindo vídeos) por uma hierarquia de cache, 

mantendo-o em cache nos nós intermediários. Mostre, por meio de um exemplo, como esses dois 

cenários podem ser vistos como duais um do outro. Explique por que uma CDN pode ser vista 
como equivalente a um multicast assíncrono. (Dica: Pense no serviço TiVo®.) 
42. Considere o seguinte cenário de um BitTorrent simplificado. Existe um enxame de 2” membros 

e, durante o período em questão, nenhum membro entra ou sai do enxame. É preciso 1 unidade 

de tempo para que um membro faça o upload ou download de um pedaço, período durante o 

qual ele só pode fazer um ou outro. Inicialmente, um membro tem o arquivo inteiro e os outros 

não têm nada. 

a. Se o arquivo alvo do enxame consiste em apenas um pedaço, qual é o tempo mínimo 
necessário para que todos os membros obtenham o arquivo? Ignore tudo exceto pelo tempo 
de upload/download. 

b. Considere que x seja a sua resposta para a pergunta anterior. Se o arquivo de destino 
do enxame, ao invés disso, consistisse em 2 pedaços, seria possível que todos os membros 
obtivessem o arquivo em menos do que 2x unidades de tempo? Por quê? 


Glossário 


3DES Triplo DES, uma versão do DES que usa três chaves, efetivamente aumentando o tamanho da chave e a segurança 
da cifração. 

3G Rede sem fios móvel de terceira geração, uma classe de tecnologia celular baseada no Acesso Múltiplo por Divisão de 
Código (Code Division Multiple Access - CDMA). 

4B/5B Um tipo de esquema de codificação de bits usado no FDDI, em que cada 4 bits de dados são transmitidos como 
uma sequência de 5 bits. 

4G Rede sem fios de quarta geração, um conjunto emergente de padrões para dar suporte a taxas de dados mais altas 
do que 3G. 

802.11 Padrão de rede sem fios do IEEE. 

802.3 Padrão Ethernet do IEEE. 

802.5 Padrão token ring do IEEE. 

802.17 Padrão de rede de pacotes em anel resiliente do IEEE. 

822 Refere-se à RFC 822, que define o formato das mensagens de correio eletrônico (e-mail) da Internet. Ver SMTP 

AAL (ATM Adaptation Layer - Camada de Adaptação ATM) Uma camada de protocolo, configurada sobre o Modo de 
Transferência Assíncrono (Asynchronous TransferMode — ATM). Duas AALs foram definidas para comunicações 
de dados, AAL3/4 e AAL5. Cada camada de protocolo oferece um mecanismo para segmentar pacotes grandes em 
células no emissor e remontar as células de volta no receptor. 

ABR (1) Available Bit Rate (Taxa de Bits Disponível). Um esquema de controle de congestionamento baseado em taxa, 
desenvolvido para uso em redes ATM. O ABR serve para permitir que uma origem aumente ou diminua sua taxa 
alocada, com base no feedback de switches dentro da rede. Compare com CBR, UBR e VBR. (2) Area Border Router. 
Roteador na borda de uma área, em um protocolo por estado do enlace. 

ACK Abreviação de acknowledgment (confirmação). Uma confirmação é enviada por um receptor de dados para indicar 
ao emissor que a transmissão teve sucesso. 

aumento aditivo/diminuição multiplicativa Estratégia de janela de congestionamento utilizada pelo TCP. O TCP abre a 
janela de congestionamento em uma taxa linear, mas a divide ao meio quando percebe perdas por consequência do 
congestionamento. Foi demonstrado que o aumento aditivo /diminuição multiplicativa é a condição necessária para 
que um mecanismo de controle de congestionamento seja estável. 

AES Advanced Encryption Standard (Padrão Avançado de Cifração) Uma cifra criptográfica que foi proposta para subs- 
tituir o DES (Data Encryption Standard). 

AF Assured Forwarding (encaminhamento garantido). Um dos comportamentos por salto propostos para o Serviços 
Diferenciados ( DiffServ). 

ALF Application Level Framing (enquadramento no nível da aplicação) Um princípio de projeto de protocolo que diz 
que os programas de aplicação entendem melhor suas necessidades de comunicação do que os protocolos de trans- 
porte de uso geral. 

AMPS Advanced Mobile Phone System (Sistema de Telefonia Móvel Avançado). Sistema de telefone celular baseado em tec- 
nologia analógica. Atualmente sendo substituído pelo sistema digital, conhecido como PCS (Personal Communication 
Services, ou Serviços de Comunicação Pessoal). 

ANSI American National Standards Institute. Agência de padronização privada dos Estados Unidos, que normalmente 
participa em processos de padronização da ISO. Responsável pelo padrão SONET. 

API Application Programming Interface (Interface de Programação de Aplicativos) Interface que os programas de aplicação 
utilizam para acessar o subsistema de rede (normalmente, o protocolo de transporte). Geralmente, é específico do 
sistema operacional. A API de sockets do Berkeley Unix é um exemplo bastante utilizado. 

área No contexto do roteamento por estado do enlace, refere-se a uma coleção de roteadores adjacentes que compartilham 
informações de roteamento completas entre eles. Um domínio de roteamento é dividido em áreas, para melhorar a 
escalabilidade. 

ARP Address Resolution Protocol (Protocolo de Resolução de Endereços) Protocolo da arquitetura da Internet, usado para 
traduzir endereços de protocolo de alto nível em endereços de hardware físicos. Comumente usado na Internet 
para mapear endereços IP em endereços Ethernet. 

ARPA Advanced Research Projects Agency (Agência de Projetos de Pesquisa Avançados) Uma das organizações de pesquisa 
e desenvolvimento dentro do Departamento de Defesa dos EUA. Responsável por patrocinar a ARPANET, bem como a 
pesquisa que levou ao desenvolvimento da Internet TCP/IP Também conhecido como DARPA, com o D significando 
“Defesa”. 

ARPANET Uma rede de comutação de pacotes de longa distância e experimental, patrocinada pela ARPA, e iniciada no 
final da década de 1960; ela se tornou o backbone da Internet em desenvolvimento. 
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ARQ Automatic Repeat reQuest (solicitação automática de repetição) Estratégia geral para enviar pacotes de modo 
confiável por um enlace não confiável. Se o emissor não receber um ACK para um pacote depois de um certo período 
de tempo, ele considera que o pacote não chegou (ou foi entregue com erros em seus bits) e o retransmite. Parar e 
esperar e janela deslizante são dois exemplos de protocolos ARQ. Compare com FEC. 

ASN.1 Abstract Syntax Notation One (Notação de Sintaxe Abstrata Um) Em conjunto com o BER (Basic Encoding Rules, ou 
regras de codificação básicas), um padrão de apresentação de formatação criado pela ISO como parte da arquitetura 
OSI. 

ATM Asynchronous Transfer Mode (Modo de Transferência Assíncrona). Uma tecnologia de rede orientada a conexão, que 
utiliza pacotes pequenos, de tamanho fixo (chamados células) para transportar dados. 

Fórum ATM Um importante órgão de definição de padrões ATM. 

autenticação Protocolo de segurança pelo qual duas partes suspeitas provam uma para a outra que elas são quem 
realmente afirmam ser. 

Autonomous System (AS) (Sistema Autônomo) Um grupo de redes e roteadores, sujeitos a uma autoridade comum e 
usando o mesmo protocolo de roteamento intradomínio. 

largura de banda Uma medida da capacidade de um enlace ou conexão, normalmente dada em unidades de bits por 
segundo. 

Bellman-Ford Um nome para o algoritmo de roteamento por vetor de distâncias, nomeado em função de seus in- 
ventores. 

BER Basic Encoding Rules (regras de codificação básicas). Regras para a codificação de tipos de dados definidos pelo 
ASN.. 

entrega de menor esforço O modelo de serviço da arquitetura atual da Internet. A entrega de uma mensagem é tentada, 
mas não é garantida. 

BGP Border Gateway Protocol (Protocolo de Roteamento de Borda) Um protocolo de roteamento interdomínios, pelo 
qual sistemas autônomos trocam informações de interconectividade. A versão mais recente é o BGP-4. 

BISYNC Binary Synchronous Communication (Comunicação Síncrona Binária). Um protocolo no nível de enlace, orientado 
a bytes, desenvolvido no final da década de 1960 pela IBM. 

preenchimento de bits Uma técnica usada para distinguir sequências de controle e dados no nível de bit. Usado pelo 
protocolo HDLC (High-Level Data Link Control, ou Controle de Enlace de Dados de Alto Nível). 

bloqueio Um termo do sistema operacional usado para descrever uma situação em que um processo suspende a execução 
enquanto espera algum evento, como uma mudança no estado de um semáforo. 

Bluetooth® Uma rede sem fios de curto alcance, usada para conectar computadores, telefones móveis e dispositivos 
periféricos, entre outras coisas. 

ponte (bridge) Um dispositivo que encaminha quadros no nível de enlace de uma rede física para outra, às vezes chamado 
switch de LAN. Compare com repetidor e roteador. 

broadcast Um método de entrega de um pacote para todos os hosts em determinada rede ou inter-rede. Pode ser im- 
plementado em hardware (por exemplo, Ethernet) ou em software (por exemplo, broadcast IP). 

CA Certification Authority (também conhecido como Certificate Authority, Autoridade Certificadora ou Autoridade 
de Certificação). Uma entidade que assina certificados digitais, prometendo assim que a chave pública contida no 
certificado pertence à entidade indicada no certificado. 

CBC Cipher Block Chaining (encadeamento de blocos da cifra). Um modo criptográfico em que cada bloco de texto às 
claras passa por um XOR com o bloco de texto cifrado anterior antes da cifração. 

CBR Constant Bit Rate (Taxa Constante de Bits) Uma classe de serviço do ATM que garante a transmissão de dados em 
uma taxa de bits constante, simulando assim um enlace de transmissão dedicado. Compare com ABR, UBR e VBR. 

CCITT O extinto Comité Consultatif Internationale de Telegraphie et Telephonie (Comitê Consultativo Internacional de 
Telegrafia e Telefonia), uma unidade da União Internacional de Telecomunicações (International Telecommunications 
Union — ITU) das Nações Unidas. Agora substituído pelo ITU-T. 

CDMA Code Division Multiple Access (Acesso Múltiplo por Divisão de Código). Uma forma de multiplexação usada nas 
redes sem fios. 

CDN Content Distribution Network (rede de distribuição de conteúdo) Uma coleção de servidores Web substitutos, 
espalhados pela Internet, que respondem a solicitações http da web no lugar do servidor. O objetivo da ampla dis- 
tribuição dos servidores substitutos é ter um substituto próximo do cliente, possibilitando a resposta mais rápida às 
suas solicitações. 

célula Um pacote ATM de 53 bytes, capaz de transportar até 48 bytes de dados. 

certificado Um documento assinado digitalmente por uma entidade, contendo o nome e a chave pública de outra 
entidade. Usado para distribuir chaves públicas. Ver também CA. 

canal Um termo de comunicação genérico, usado neste livro para indicar uma conexão lógica entre dois processos. 

soma de verificação Normalmente, uma soma em complemento de um sobre alguns ou todos os bytes de um pacote, 
calculada e anexada ao pacote pelo emissor. O receptor recalcula a soma de verificação e a compara com a que foi 
enviada na mensagem. As somas de verificação são usadas para detectar erros em um pacote e também podem ser 
usadas para verificar se o pacote foi entregue ao host correto. O termo soma de verificação às vezes também é usado 
(incorretamente) para se referir genericamente a códigos de detecção de erros. 
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código de fichas Sequência aleatória de bits que passa por uma operação XOR com o fluxo de dados a fim de implementar 
a técnica de espalhamento espectral por sequência direta. 

CIDR Classless Interdomain Routing (Roteamento Interdomínios sem Classes) Um método de agregar rotas que trata um 
bloco de endereços IP contíguos da Classe C como uma única rede.! 

comutação de circuitos Uma estratégia geral para comutar dados através de uma rede. Envolve o estabelecimento de 
um caminho (circuito) dedicado entre a origem e o destino. Compare com comutação de pacotes. 

cliente O solicitante de um serviço em um sistema distribuído. 

CLNP Connectionless Network Protocol (Protocolo de Rede Sem Conexão). O equivalente ISO ao IP da Internet. 

recuperação de relógio O processo de derivar um valor de relógio válido a partir de um sinal digital transmitido de forma 
serial. 

canais lógicos concorrentes Multiplexação de vários canais lógicos do tipo parar e esperar em um único enlace ponto 
a ponto. Nenhuma ordem de entrega é imposta. Esse mecanismo foi usado pelo protocolo IMP (Interface Message 
Processor) da ARPANET. 

congestionamento Um estado resultante de muitos pacotes disputando por recursos limitados (por exemplo, largura de 
banda do enlace e espaço de buffer nos roteadores ou switches), o que pode forçar o roteador (ou switch) a descartar 
pacotes. 

controle de congestionamento Qualquer estratégia de gerenciamento de recursos da rede que tenha, como seu objetivo, 
a diminuição ou a prevenção do congestionamento. Um mecanismo de controle de congestionamento pode ser 
implementado nos roteadores (ou switches) dentro da rede, pelos hosts nas bordas da rede ou por uma combinação 
destes. 

conexão Em geral, um canal que precisa ser estabelecido antes do uso (por exemplo, por meio da transmissão de alguma 
informação de configuração). Por exemplo, o TCP provê uma abstração de conexão que oferece a entrega confiável 
e ordenada de um fluxo de bytes. As redes orientadas à conexão, como ATM, normalmente oferecem uma abstração 
de circuito virtual. 

protocolo sem conexões Um protocolo em que os dados podem ser enviados sem qualquer configuração prévia. O IP é 
um exemplo de tal protocolo. 

troca de contexto Uma operação em que um sistema operacional suspende a execução de um processo e inicia a execução 
de outro. Uma troca de contexto envolve salvar o estado do primeiro processo (por exemplo, o conteúdo de todos os 
registradores) e carregar o estado do segundo processo. 

carga controlada Uma das classes de serviço disponíveis na arquitetura de Serviços Integrados (IntServ) da Internet. 

CRC Cyclic Redundancy Check (Verificação de Redundância Cíclica) Um código de detecção de erros calculado sobre os 
bytes que compõem um pacote e depois anexado ao pacote pelo hardware da rede (por exemplo, o adaptador Ethernet). 
O CRC oferece detecção de erros mais eficaz do que uma soma de verificação simples. 

switch crossbar Um projeto de switch simples em que cada entrada é conectada diretamente a cada saída, e a porta de 
saída é responsável por resolver disputas. 

CSMA/CD Carrier Sense Multiple Access with Collision Detection (Acesso Múltiplo com Detecção de Portadora / Detecção 
de Colisão). O CSMA/CD é uma funcionalidade do hardware de rede. “Acesso Múltiplo com Detecção de Portadora” 
significa que várias estações podem escutar o enlace e detectar quando ele está em uso ou ocioso; “Detecção de 
Colisão” indica que, se duas ou mais estações estiverem transmitindo no enlace simultaneamente, elas detectarão a 
colisão de seus sinais. O Ethernet é a tecnologia mais conhecida que utiliza CSMA/CD. 

cut-through Uma forma de comutação ou encaminhamento em que um pacote começa a ser transferido para uma saída 
antes que tenha sido completamente recebido pelo nó fazendo a comutação, reduzindo assim a latência através do nó. 

datagrama A unidade de transmissão básica na arquitetura da Internet. Um datagrama contém toda a informação 
necessária para entregá-lo ao seu destino, semelhante a uma carta no sistema postal. As redes de datagrama são redes 
sem conexões. 

DCE Distributed Computing Environment (Ambiente de Computação Distribuída). Um conjunto de protocolos e padrões 
baseados em RPC, que dão suporte a computação distribuída. Definido pelo OSE 

DDCMP Digital Data Communication Message Protocol (Protocolo de Mensagens para Comunicação de Dados Digitais). 
Um protocolo no nível de enlace, orientado a bytes, usado na DECNET da Digital Equipment Corporation (DEC). 

DDoS Distributed Denial of Service (Negação de Serviço Distribuída). Um ataque de negação de serviço originado em um 
conjunto de nós. Cada nó atacante só precisa colocar apenas uma carga pequena sobre a máquina de destino, mas a 
carga agregada de todos os nós ataca e consegue inundar essa máquina. 

DECbit Um esquema de controle de congestionamento em que os roteadores notificam as extremidades quanto ao 
congestionamento iminente, marcando um bit no cabeçalho dos pacotes roteados. As extremidades diminuem suas 
taxas de envio quando certa porcentagem dos pacotes recebidos tiver o bit marcado. 

decifração O ato de reverter um processo de cifração para recuperar os dados de uma mensagem cifrada. 

produto atraso x largura de banda O produto do tempo de ida e volta (RTT) pela largura de banda de uma rede. Indica 
uma medida de quantos dados podem estar em trânsito na rede. 


IN.T. Mais especificamente, o CIDR desconsidera a existência de classes, usando uma máscara para determinar a parte 
relativa ao endereço de rede de um endereço IP. 
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demultiplexação Uso de informações contidas no cabeçalho de um pacote para direcioná-lo para cima na pilha de 
protocolos. Por exemplo, o IP utiliza o campo Número-Protocolo no cabeçalho IP para decidir a qual protocolo da 
camada superior (ou seja, TCP UDP) um pacote pertence, e o TCP usa o número de porta para demultiplexar um 
pacote TCP para o processo de aplicação correto. Compare com multiplexação. 

chave de demultiplexação Um campo em um cabeçalho de pacote usado para permitir que haja demultiplexação (por 
exemplo, o campo Número-Protocolo do IP). 

multicast em modo denso Modo do PIM (Protocol Independent Multicast, ou multicast independente de protocolo) 
usado quando a maioria dos roteadores ou hosts precisa receber pacotes de multicast. 

DES Data Encryption Standard (Padrão de Cifração de Dados). Um algoritmo para cifração de dados baseado em uma 
chave secreta de 64 bits. 

DHCP Dynamic Host Configuration Protocol (Protocolo de Configuração Dinâmica de Host) Um protocolo usado por um 
host, quando é inicializado, descobre várias informações da rede, como seu endereço IP. 

DHT Distributed Hash Table (tabela de hash distribuída). Uma técnica pela qual uma mensagem é roteada para uma 
máquina que mantém um objeto em particular, com base no nome do objeto. O objeto é mapeado por um identifi- 
cador exclusivo por meio do cálculo do seu hash, com cada nó intermediário encaminhando, ao longo do percurso, 
a mensagem para um outro nó que possa interpretar um prefixo maior do seu identificador. DHTs normalmente são 
usadas em redes peer-to-peer. 

Serviços Diferenciados (Differentiated Services - DiffServ) Uma nova arquitetura utilizada para oferecer um serviço 
melhor do que o “melhor esforço” na Internet. Tem sido proposto como uma alternativa aos Serviços Integrados 
(Integrated Services — IntServ). 

sequência direta Uma técnica de espalhamento espectral que envolve fazer a operação de XOR do fluxo de dados com 
uma sequência de bits aleatória, conhecida como código de fichas. 

vetor de distâncias Um algoritmo de determinação de caminhos de menor custo usado utilizada para roteamento. Cada 
nó anuncia informações de acessibilidade e os custos associados aos seus vizinhos imediatos, usando as atualizações 
que recebe para construir sua tabela de encaminhamento. O Protocolo de Informações de Roteamento (Routing 
Information Protocol — RIP) utiliza um algoritmo de vetor de distâncias. Compare com estado de enlace. 

DMA Direct Memory Access (acesso direto à memória). Uma técnica para conectar hosts a dispositivos de E/S, em que o 
dispositivo lê os dados da memória do host e grava dados diretamente na memória do host. Ver também PIO. 

DNA/DECnet Digital Network Architecture (Arquitetura de Rede Digital) Uma arquitetura baseada no modelo OSI que 
provê um modelo de rede sem conexões e um protocolo de transporte orientado a conexões. 

DNS Domain Name System (Sistema de Nomes de Domínio). O sistema de nomes distribuídos da Internet, usado para 
traduzir nomes de host (por exemplo, cicada.cs.princeton.edu) em endereços IP (por exemplo, 192.12.69.35). O DNS 
é implementado por uma hierarquia de servidores de nomes. 

domínio Pode se referir a um contexto no espaço hierárquico de nomes do DNS (por exemplo, o domínio “.edu”) ou a 
uma região da Internet que é tratada como uma única entidade para fins de roteamento hierárquico. O segundo é 
equivalente ao sistema autônomo. 

DoS Denial of Service (Negação de Serviço). Uma situação em que um nó atacante inunda um nó de destino com tanto 
trabalho (muitos pacotes) que ele efetivamente impede que os usuários legítimos acessem o nó; logo, eles negam 
serviço a estes usuários. 

DS3 Um serviço de enlace de transmissão de 44,7 Mbps, oferecido pela companhia telefônica. Também chamado T3. 

DSL Digital Subscriber Line (Linha de Assinante Digital). Uma família de padrões para transmitir dados por linhas 
telefônicas de par trançado em velocidades de muitos megabits por segundo. 

ACK duplicado Uma retransmissão de uma confirmação do TCP O ACK duplicado não confirma quaisquer dados novos. 
O recebimento de múltiplos ACKs duplicados dispara o mecanismo de retransmissão rápida do TCP 

DVMRP Distance Vector Multicast Routing Protocol (Protocolo de Roteamento Multicast por Vetor de Distâncias) O 
protocolo de roteamento multicast usado pela maioria dos roteadores no MBone. 

DWDM Dense Wavelength Division Multiplexing (Multiplexação por Divisão de Comprimento de Onda Densa). 
Multiplexação de múltiplos comprimentos de luz (cores) em uma única fibra física. A técnica é “densa” no sentido de 
que uma grande quantidade de tamanhos de onda ópticos pode ser admitida. 

ECN Explicit Congestion Notification (notificação explícita de congestionamento). Uma técnica pela qual os roteadores 
informam aos hosts finais sobre o congestionamento, marcando um flag nos pacotes que estão encaminhando. Usado 
em conjunto com algoritmos ativos de gerenciamento de fila, como o RED (Random Early Detection, ou Detecção 
Aleatória Antecipada). 

EF Expedited Forwarding (encaminhamento expresso). Um dos comportamentos por salto propostos para a abordagem 
de Serviços Diferenciados (DiffServ). 

EGP Exterior Gateway Protocol. Um antigo protocolo de roteamento interdomínios da Internet, que era usado por 
gateways externos (roteadores) de sistemas autônomos para trocar informações de roteamento com outros sistemas 
autônomos. Substituído pelo BGP 

encapsulamento A operação, realizada por um protocolo da camada inferior, de anexar um cabeçalho e/ou rodapé 
(trailer) específico de protocolo a uma mensagem passada por um protocolo da camada superior. À medida que 
uma mensagem atravessa a pilha de protocolos, ela acumula uma sequência de cabeçalhos, dos quais o mais externo 
corresponde ao protocolo mais baixo da pilha. 
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cifração O ato de aplicar uma função de transformação aos dados, com a intenção de que somente o receptor dos dados 
possa lê-los (depois de aplicar a função inversa, a decifração). A cifração geralmente depende de um segredo comparti- 
lhado por emissor e receptor, ou de um par de chaves pública/privada. 

Ethernet Uma tecnologia de rede local popular, que utiliza CSMA/CD e tem uma largura de banda de 10 Mbps. Uma 
Ethernet é apenas um fio passivo; todos os aspectos da transmissão Ethernet são completamente implementados 
pelos adaptadores do host. 

recuo exponencial Uma estratégia de retransmissão que dobra o valor do tempo limite de expiração toda vez que um 
pacote é retransmitido. 

problema do nó exposto Situação que ocorre em uma rede sem fios quando dois nós recebem sinais de uma origem 
comum, mas cada um é capaz de alcançar outros nós que não recebem esse sinal. 

LAN estendida Uma coleção de LANs conectadas por pontes. 

malha A parte de um switch que realmente realiza a comutação, ou seja, move pacotes da entrada para a saída. Compare 
com porta. 

enfileiramento justo (Fair Queuing - FQ) Um algoritmo de enfileiramento baseado em rodízio, que previne que um 
processo mal comportado capture uma parte arbitrariamente grande da capacidade da rede. 

retransmissão rápida Uma estratégia usada pelo TCP que tenta evitar eventos de expiração do tempo limite na presença de 
pacotes perdidos. O TCP retransmite um segmento depois de receber três ACKs duplicados consecutivos, confirmando 
os dados até esse segmento (sem incluí-lo). 

FDDI Fiber Distributed Data Interface (Interface de Dados Distribuídos por Fibra). Uma tecnologia de rede token ring de 
alta velocidade, projetada para ser executada em cima de fibras ópticas. 

FEC (1) Forward Error Correction (Correção Antecipada de Erros). Uma estratégia geral para recuperar-se de erros de bits 
introduzidos em pacotes de dados sem ter que retransmitir o pacote. Informações redundantes são incluídas em cada 
pacote, as quais podem ser usadas pelo receptor para determinar quais bits estão incorretos em um pacote. Compare 
com ARQ. (2) Forwarding Equivalence Class (classe de equivalência de encaminhamento). Um conjunto de pacotes 
que devem receber o mesmo tratamento de encaminhamento em um roteador. Rótulos MPLS (Multiprotocol Label 
Switching, ou Comutação de Rótulos Multiprotocolo) normalmente são associados com FECSs. 

Fiber Channel (Canal de Fibra) Um protocolo de enlace bidirecional normalmente usado para conectar computadores 
(normalmente, supercomputadores) a periféricos. A tecnologia de Fiber Channel possui uma largura de banda de 100 
MBps e pode cobrir até 30m. Usado da mesma maneira que a interface HiPPI (High-Performance Parallel Interface, 
ou Interface Paralela de Alto Desempenho). 

firewall Um roteador que foi configurado para filtrar (não encaminhar) pacotes de certas origens e destinos. Usado para 
impor uma política de segurança. 

controle de fluxo Um mecanismo pelo qual o receptor de dados limita a taxa de transmissão do emissor, de modo que 
os dados não cheguem rápido demais para serem processados. Compare com controle de congestionamento. 

especificação de fluxo Especificação dos requisitos de largura de banda e atraso de um fluxo apresentados à rede para 
estabelecer uma reserva. Usada com o RSVP (Resource Reservation Protocol, ou Protocolo de Reserva de Recursos). 

encaminhamento A operação realizada por um roteador sobre cada pacote recebendo-o em uma entrada, decidindo 
para que saída enviá-lo e enviando-o para lá. 

eabela de encaminhamento A tabela mantida em um roteador, que lhe permite tomar decisões sobre como encami- 
nhar pacotes. O processo de montagem da tabela de encaminhamento é chamado roteamento, e assim a tabela de 
encaminhamento às vezes é chamada de tabela de roteamento. Em algumas implementações, as tabelas de roteamento 
e encaminhamento são estruturas de dados separadas. 

fragmentação/remontagem Um método usado para transmissão de mensagens maiores do que a MTU da rede. As 
mensagens são fragmentadas em pequenas partes pelo emissor e remontadas pelo receptor. 

quadro Outro nome para um pacote, normalmente usado na referência a pacotes enviados por um único enlace, em vez 
de uma rede inteira. Um problema importante é como o receptor detecta o início e o final de um quadro, um problema 
conhecido como enquadramento. 

Frame Relay Um serviço público de comutação de pacotes, orientado à conexão, oferecido pela companhia telefônica. 

salto em frequência Uma técnica de espalhamento espectral que envolve a transmissão de dados por uma sequência 
aleatória de frequências. 

FTP File Transfer Protocol (Protocolo de Transferência de Arquivos). O protocolo padrão da arquitetura da Internet utilizado 
para transferir arquivos entre hosts. Ele opera em cima do TCP. 

GMPLS Generalized MPLS (MPLS Generalizado). Permite que o IP execute de forma nativa em cima de redes comutadas 
opticamente. 

Gopher Um antigo serviço de informação da Internet. 

GPRS General Packet Radio Service (Serviço Geral de Pacotes por Rádio). Um serviço de transmissão de pacotes fornecido 
por redes celulares sem fios. 

GSM Global System for Mobile communication (Sistema Global para Comunicações Móveis). Sistema de telefonia celular 
digital sendo empregado por todo o mundo. 

H.323 Protocolo de controle de sessão, normalmente usado para telefonia na Internet. 

handle Em programação, um identificador ou ponteiro que é usado para acessar um objeto. 

endereço de hardware O endereço no nível de enlace usado para identificar o adaptador do host na rede local. 
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HDLC High-Level Data Link Control (Controle de Enlace de Dados de Alto Nível). Um protocolo no nível de enlace pa- 
dronizado pela ISO. Ele utiliza o preenchimento de bits para solucionar o problema do enquadramento. 

problema do nó oculto Situação que ocorre em uma rede sem fios quando dois nós estão enviando dados a um destino 
comum, mas um não sabe que o outro existe. 

roteamento hierárquico Um esquema de roteamento multinível que usa a estrutura hierárquica do espaço de endereços 
como base para tomar decisões de encaminhamento. Por exemplo, os pacotes poderiam primeiro ser roteados para 
uma rede de destino e depois para um host específico nessa rede. 

host Um computador ligado a uma ou mais redes, que admite usuários e executa programas de aplicação. 

HTML HyperText Markup Language (Linguagem de Marcação de HiperTexto). Uma linguagem utilizada para construir 
páginas da World Wide Web. 

HTTP HyperText Transport Protocol (Protocolo de Transferência de Hipertexto). Um protocolo no nível de aplicação, 
baseado em um paradigma de solicitação /resposta e usado na World Wide Web. O HTTP utiliza conexões TCP para 
transferir dados. 

IAB Internet Architecture Board (Conselho de Arquitetura da Internet). O órgão principal que supervisiona o desenvol- 
vimento e a padronização de protocolos da arquitetura Internet, conhecido originalmente como Internet Activities 
Board (Conselho de Atividades da Internet). 

iBGP Interior Border Gateway Protocol (BGP interno), o protocolo utilizado para a troca de informações de roteamento 
interdomínios entre os roteadores no mesmo domínio. 

ICMP Internet Control Message Protocol (Protocolo de Mensagens de Controle da Internet). Esse protocolo é uma parte 
integral do IP Ele permite que um roteador ou host de destino se comunique com a origem, normalmente para in- 
formar um erro no processamento de um datagrama IP. 

IEEE Institute for Electrical and Electronics Engineers (Instituto de Engenheiros Eletricistas e Eletrônicos). Uma sociedade 
profissional para engenheiros, que também define padrões para redes, incluindo a série 802 de padrões de LAN. 
IETF Internet Engineering Task Force (Força-Tarefa de Engenharia da Internet). A organização principal responsável por 

desenvolver padrões e melhores práticas para a Internet. 

IMAP Internet Message Access Protocol (Protocolo de Acesso a Correio da Internet). Um protocolo da camada de aplicação 
que permite a um usuário obter seu correio eletrônico (e-mail) de um servidor de correio. 

IMP-IMP Um protocolo no nível de enlace, orientado a bytes, usado na ARPANET original. 

Serviços Integrados (Integrated Services - IntServ) Normalmente usada para significar uma rede de comutação de 
pacotes que efetivamente pode dar suporte tanto a dados convencionais de computador quanto a áudio e vídeo em 
tempo real. Além disso, é o nome dado a um modelo de serviço proposto para a Internet, que está sendo projetado 
para substituir o modelo atual de serviços de melhor esforço. 

integridade No contexto de segurança de redes, um serviço que garante que uma mensagem recebida é a mesma que 
foi enviada. 

roteamento interdomínios O processo de trocar informações de roteamento entre diferentes domínios de roteamento. 
O BGP é um exemplo de um protocolo de roteamento interdomínios. 

inter-rede Uma coleção de redes de comutação de pacotes (possivelmente heterogêneas), interconectadas por roteadores. 
Também chamada internetwork ou internet. 

Internet A inter-rede global baseada na arquitetura Internet (TCP/IP), conectando milhões de hosts no mundo 
inteiro. 

interoperabilidade A capacidade de equipamentos de hardware heterogêneos e de aplicações de software de múltiplos 
fornecedores se comunicarem por meio da troca correta de mensagens. 

interrupção Um evento (geralmente gerado por um dispositivo de hardware) que diz ao sistema operacional para parar 
sua atividade atual e tomar alguma ação. Por exemplo, uma interrupção é usada para avisar ao sistema operacional 
que chegou um pacote da rede. 

roteamento intradomínio A troca de informações de roteamento dentro de um único domínio ou sistema autônomo. 
O RIP e o OSPF são exemplos de protocolos intradomínio. 

IP Internet Protocol (Protocolo Internet). Um protocolo que fornece serviço de melhor esforço e sem conexões para a 
entrega de datagramas pela Internet. 

IPng Internet Protocol Next Generation (Protocolo Internet de Nova Geração, agora conhecido como IPv6). Nova versão 
do IP que fornece um espaço de endereços maior e mais hierárquico, e outros novos recursos. 

IPsec IP Security (Segurança IP). Uma arquitetura para prover autenticação, privacidade e integridade de mensagens, 
entre outros serviços de segurança para a arquitetura Internet. 

IRTE Internet Research Task Force (Força-Tarefa de Pesquisa da Internet). Uma força-tarefa responsável por definir direções 
de pesquisa e desenvolvimento para a Internet. 

ISDN Integrated Services Digital Network (Rede Digital de Serviços Integrados). Um serviço de comunicação digital 
oferecido pelas prestadoras de serviços telefônicos e padronizado pela ITU-T. A ISDN combina serviços de conexão 
de voz e dados digitais em um único meio físico. 

IS-IS Intermediate System to Intermediate System (Sistema Intermediário para Sistema Intermediário). Um protocolo de 
roteamento por estado de enlace, semelhante ao OSPF (Open Shortest Path First, ou Protocolo Aberto de Menor Rota 
Primeiro). 
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ISO International Standards Organization (Organização Internacional de Padronização). A agência internacional que 
propôs a arquitetura OSI de sete camadas, e um conjunto de protocolos que não obteve sucesso comercial. 

ITU-T Um subcomitê da International Telecommunications Union (ITU), um órgão global que propõe padrões técnicos 
para todas as áreas da comunicação analógica e digital internacional. A ITU-T lida com padrões para telecomunicações, 
principalmente ATM. 

jitter Variação na latência da rede. Uma grande flutuação tem um impacto negativo sobre a qualidade das aplicações 
de vídeo e áudio. 

JPEG Joint Photographic Experts Group (Grupo de Especialistas em Fotografia). Normalmente usado para se referir a um 
algoritmo bastante utilizado para compactação de imagens paradas, desenvolvido pela JPEG. 

Kerberos Um sistema de autenticação baseado em TCP/IP desenvolvido no MIT, no qual dois hosts utilizam uma terceira 
entidade de confiança para autenticar um ao outro. 

distribuição de chaves Mecanismo pelo qual os usuários descobrem as chaves públicas uns dos outros através da troca 
de certificados assinados digitalmente. 

LAN Local Area Network (Rede Local). Uma rede baseada em qualquer tecnologia de rede física que seja projetada para 
cobrir distâncias de até alguns quilômetros (por exemplo, Ethernet ou FDDI). Compare com SAN, MAN e WAN. 

Switch de LAN Outro termo para uma ponte, normalmente aplicado a uma ponte com muitas portas. Também chamado 
de switch Ethernet, se a tecnologia da camada de enlace que ele admite for Ethernet. 

latência Uma medida do tempo gasto para um único bit se propagar de uma extremidade de um enlace ou canal até a 
outra. A latência é medida estritamente em termos de tempo. 

LDAP Lightweight Directory Access Protocol (Protocolo Leve de Acesso a Diretórios). Um subconjunto do serviço de 
diretórios X.500, que se tornou recentemente um serviço de diretórios popular para informações sobre os usuários. 

LER Label Edge Router (roteador de borda por rótulo). Um roteador na borda de uma nuvem MPLS (Multiprotocol Label 
Switching). Realiza uma busca completa do IP nos pacotes IP recebidos, e depois aplica rótulos a eles como resultado 
da busca. 

enlace Uma conexão física entre dois nós de uma rede. Ele pode ser implementado por cabo de cobre ou fibra óptica, ou 
então pode ser um enlace sem fio (por exemplo, usando um satélite). 

protocolo no nível de enlace Um protocolo que é responsável por entregar quadros por uma rede onde os nós estão 
conectados diretamente (por exemplo, um enlace Ethernet, token ring ou ponto a ponto). (Também chamado protocolo 
da camada de enlace.) 

estado de enlace Um algoritmo de determinação de caminhos de menor custo usado para roteamento. As informações 
sobre vizinhos conectados diretamente e custos do enlace atual são inundadas para todos os roteadores; cada roteador 
utiliza essa informação para montar uma visão da rede que serve como base para decisões de encaminhamento. O 
protocolo de roteamento OSPF utiliza um algoritmo de estado do enlace. Compare com vetor de distâncias. 

LSR Label Switching Router (roteador de comutação de rótulos). Um roteador que executa protocolos de controle do IP, 
mas utiliza o algoritmo de encaminhamento por comutação de rótulos do MPLS (Multiprotocol Label Switching). 
MAC Media Access Control (Controle de Acesso ao Meio). Algoritmos utilizados para controlar o acesso a redes com meio 

compartilhado, como Ethernet e FDDI (Fiber Distributed Data Interface). 

MACA Multiple Access with Collision Avoidance (Acesso Múltiplo com Prevenção de Colisão). Algoritmo distribuído usado 
para mediar o acesso a um meio compartilhado. 

MACAW Multiple Access with Collision Avoidance for Wireless (Acesso Múltiplo com Prevenção de Colisão para Redes Sem 
Fio). Melhoria do algoritmo MACA geral, para melhorar o suporte a redes sem fio. Usado pelo 802.11. 

MAN Metropolitan Area Network (rede metropolitana). Uma rede baseada em qualquer uma das novas tecnologias de 
rede que operam em altas velocidades (até vários Gbps) e cobrindo distâncias grandes o suficiente para se espalharem 
por uma área metropolitana. Compare com SAN, LAN e WAN. 

Manchester Um esquema de codificação de bits que transmite o OU exclusivo (XOR) do valor do relógio com os dados 
codificados via NRZ. Usado nas redes Ethernet. 

MBone Multicast Backbone. Uma rede lógica construída em cima da Internet, na qual os roteadores preparados para 
fazer multicast utilizam o tunelamento para encaminhar datagramas multicast pela Internet. 

MD5 Message Digest (Resumo de Mensagens) versão 5. Um algoritmo criptográfico eficiente de soma de verificação, 
normalmente usado para verificar se o conteúdo de uma mensagem permanece inalterado. 

MIB Management Information Base (Base de Informações de Gerenciamento). Define o conjunto de variáveis relacionadas 
à rede que podem ser lidas ou gravadas em um nó da rede. A MIB é usada em conjunto com o SNMP (Simple Network 
Management Protocol, ou Protocolo Simples de Gerenciamento de Rede). 

MIME Multipurpose Internet Mail Extensions (Extensões Multifunção para Mensagens de Internet). As especificações 
para converter dados binários (como arquivos de imagem) em texto ASCII, para que possam ser enviados por correio 
eletrônico. 

Mosaic Um navegador gráfico da World Wide Web popular e gratuito, desenvolvido no National Center for Supercomputing 
Applications, na Universidade do Illinois. 

MP3 MPEG Layer 3. Padrão de compactação de áudio utilizado com MPEG. 

MPEG Moving Picture Experts Group (Grupo de Especialistas em Imagens em Movimento). Normalmente utilizado para 
se referir a um algoritmo para compactação de fluxos de vídeo, desenvolvido pelo MPEG. 
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MPLS Multiprotocol Label Switching (Comutação de Rótulos Multiprotocolo). Uma coleção de técnicas utilizadas para 
permitir que roteadores IP anexem rótulos aos pacotes. 

MSDP Multicast Source Discovery Protocol (Protocolo Multicast de Descoberta de Origem). Um protocolo usado para 
facilitar o multicast interdomínios. 

MTU Maximum Transmission Unit (Unidade Máxima de Transmissão). O tamanho do maior pacote que pode ser enviado 
por uma rede física. 

multicast Uma forma especial de broadcast em que os pacotes são entregues a um subgrupo especificado dos hosts da 
rede. 

multiplexação Combinação de canais distintos em um único canal da camada inferior. Por exemplo, canais TCP e UDP 
separados são multiplexados em um único canal IP host a host. A operação inversa, a demultiplexação, ocorre no 
host receptor. 

tradução de nomes A ação de traduzir nomes de host (que são fáceis para os humanos lerem) em seus endereços 
correspondentes (que as máquinas podem ler). Ver DNS. 

NAT Network Address Translation (Tradução de Endereços de Rede). Uma técnica para estender o espaço de endereços 
IP que envolve a tradução entre endereços IP globalmente entendidos e endereços apenas locais, na borda de uma 
rede ou de uma instalação de rede. 

NDR Network Data Representation (Representação de Dados de Rede). O padrão de codificação de dados usado no 
Distributed Computing Environment (DCE), conforme definido pela Open Software Foundation. O NDR utiliza uma 
estratégia de receptor-acerta, e insere um rótulo de arquitetura na frente de cada mensagem. 

protocolo no nível de rede Um protocolo que é executado em cima de redes de comutação, diretamente acima do nível 
de enlace. 

NES Network File System (Sistema de Arquivos de Rede). Um sistema de arquivos distribuídos popularmente, desenvolvido 
pela Sun Microsystems. O NFS é baseado no SunRPC, um protocolo de RPC desenvolvido pela Sun. 

NIST National Institute for Standards and Technology (Instituto Nacional de Padrões e Tecnologia). O órgão de padroni- 
zação oficial dos EUA. 

nó Um termo genérico usado para sistemas computacionais individuais que compõem uma rede. Os nós incluem 
computadores de uso geral, switches e roteadores. 

NRZ Non-Return to Zero (Não Retorno ao Zero). Um esquema de codificação de bits que codifica um 1 como o sinal alto 
e um 0 como o sinal baixo. 

NRZI Non-Return to Zero Inverted (Não Retorno ao Zero Invertido). Um esquema de codificação de bits que faz uma 
transição do sinal atual para codificar um 1 e permanece no sinal atual para codificar um 0. 

NSF National Science Foundation (Fundação Nacional de Ciência). Uma agência do governo dos Estados Unidos que 
patrocina a pesquisa científica nos Estados Unidos, incluindo a pesquisa sobre redes e sobre a infraestrutura da 
Internet. 

OC Optical Carrier (Portadora Óptica). O prefixo para várias taxas de transmissão óptica SONET. Por exemplo, OC-1 
refere-se ao padrão SONET para transmissão a 51,84 Mbps sobre fibra óptica. Um sinal OC-n difere de um sinal STS-n 
apenas porque o sinal OC-n é embaralhado para transmissão óptica. 

ONC Open Network Computing (Computação para Rede Aberta). Uma versão do SunRPC que foi padronizada para a 
Internet. 

OSF Open Software Foundation (Fundação de Software Aberto). Um consórcio de fornecedores de computador que definiu 
padrões para a computação distribuída, incluindo o formato de apresentação NDR (National Data Representation). 

switch óptico Um dispositivo de comutação que encaminha ondas de luz ópticas da porta de entrada para a porta de 
saída sem convertê-las para o formato elétrico. 

OSI Open Systems Interconnection (Interconexão de Sistemas Abertos). O modelo de referência de rede em sete camadas, 
desenvolvido pela ISO, que orienta o projeto de padrões de protocolos ISO e ITU-T. 

OSPF Open Shortest Path First (Protocolo Aberto de Menor Rota Primeiro). Um protocolo de roteamento desenvolvido 
pela IETF para a arquitetura Internet. O OSPF é baseado em um algoritmo de estado do enlace, no qual cada nó cons- 
trói uma topografia da Internet e a utiliza para tomar decisões de encaminhamento. 

overlay Uma rede virtual (lógica) executada em cima de uma rede física existente. Os nós overlay se comunicam entre si 
através de túneis, ao invés de enlaces físicos. Os overlays normalmente são usados para implantar novos serviços de 
rede, visto que eles não exigem a cooperação da infraestrutura de rede existente. 

pacote Uma unidade de dados enviada por uma rede de comutação de pacotes. Ver também quadro e segmento. 

comutação de pacotes Uma estratégia geral para a comutação de dados através de uma rede. A comutação de pacotes 
utiliza a comutação armazenar-e-encaminhar de unidades de dados discretas, chamadas pacotes, e implica multi- 
plexação estatística. 

participantes Um termo genérico usado para indicar os processos, protocolos ou hosts que estão trocando mensagens 
uns com os outros. 

PAWS Protection Against Wrapped Sequence numbers (proteção contra reinício Cíclico de números de sequência). Projetar 
um protocolo de transporte com um espaço de números de sequência grande o suficiente para proteger contra o reinício 
cíclico destes números, em uma rede onde os pacotes podem ser atrasados por um longo período de tempo. 
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PDU Protocol Data Unit (Unidade de Dados de Protocolo). Outro nome para um pacote ou quadro. 

peer (par) Um correspondente em outra máquina com o qual um módulo de protocolo interopera para implementar 
algum serviço de comunicação. 

redes peer-to-peer Uma classe geral de aplicações que integra lógica de aplicação (por exemplo, armazenamento de 
arquivos) com roteamento. Exemplos populares são BitTorrent e Gnutella. Protótipos de pesquisa normalmente 
utilizam tabelas de hash distribuídas. 

PEM Privacy Enhanced Mail (E-mail com Privacidade). Extensões ao correio eletrônico (e-mail) da Internet, que dão 
suporte à proteção da privacidade e da integridade. Ver também PGP. 

PGP Pretty Good Privacy (Privacidade Muito Boa). Uma coleção de aplicativos de domínio público que fornece mecanis- 
mos de privacidade e autenticação utilizando RSA, e que usa uma rede de confiança para a distribuição de chaves 
públicas. 

PHB Per-Hop Behavior (Comportamento por Salto). Comportamento de roteadores individuais na arquitetura de Serviços 
Diferenciados (DiffServ). AF e FF são dois PHBs propostos. 

protocolo de nível físico A camada mais baixa da pilha de protocolos OSI. Sua função principal é codificar bits nos sinais 
que são propagados pelo meio de transmissão físico. 

piconet Rede sem fios que cobre curtas distâncias (por exemplo, 10m). Usada para conectar computadores de escritório 
(laptops, impressoras, PDAs, estações de trabalho etc.) sem cabos. 

PIM Protocol Independent Multicast (Multicast Independente de Protocolo). Um protocolo de roteamento multicast que 
pode ser construído em cima de diferentes protocolos de roteamento unicast. 

Ping Um utilitário do Unix usado para testar o RTT (Round-Trip Time, ou tempo de ida e volta) para vários hosts da 
Internet. O ping envia uma mensagem ICMP ECHO REQUEST, e o host remoto envia de volta uma mensagem 
ECHO RESPONSE. 

PIO Programmed Input/Ouput (entrada/saída programada). Uma técnica para conectar hosts a dispositivos de E/S, em 
que a CPU lê e escreve dados no dispositivo de E/S. Ver também DMA. 

envenenamento reverso Usada em conjunto com o horizonte dividido. Uma técnica heurística para evitar laços de 
roteamento nos protocolos de roteamento por vetor de distâncias. 

porta Um termo genérico normalmente usado para indicar o ponto em que um usuário da rede se conecta a essa rede. 
Em um switch, uma porta indica a entrada ou saída em que os pacotes são recebidos e enviados. 

POTS Plain Old Telephone Service (Sistema de Telefonia Tradicional). Usado para indicar o serviço telefônico existente, ao 
contrário de ISDN, Voz sobre IP (Voice over IP - VOIP) ou outras tecnologias que as companhias telefônicas oferecem 
agora ou poderão oferecer no futuro. 

PPP Point-to-Point Protocol (Protocolo Ponto a Ponto). Protocolo da camada de enlace de dados normalmente usado 
para conectar computadores por uma linha discada. 

processo Uma abstração fornecida por um sistema operacional para permitir que diferentes operações ocorram si- 
multaneamente. Por exemplo, cada aplicação do usuário normalmente é executada dentro do seu próprio processo, 
enquanto diversas funções do sistema operacional ocorrem em outros processos. 

modo promíscuo Um modo de operação para um adaptador de rede em que ele recebe todos os quadros transmitidos 
na rede, não apenas aqueles endereçados para ele. 

protocolo Uma especificação de uma interface entre módulos sendo executados em diferentes máquinas, bem como 
o serviço de comunicação que esses módulos implementam. O termo também é utilizado para se referir a uma im- 
plementação do módulo que atende a essa especificação. Para distinguir entre esses dois usos, a interface normalmente 
é chamada de especificação de protocolo. 

proxy Um agente que é colocado entre um cliente e o servidor, interceptando mensagens e oferecendo algum serviço. 
Por exemplo, um proxy pode “tomar o lugar” de um servidor, respondendo a solicitações de clientes, talvez usando 
dados que tenha mantido em cache, sem contatar o servidor. 

pseudocabeçalho Um subconjunto de campos do cabeçalho IP que são passados para os protocolos de transporte TCP e 
UDP para uso em seu cálculo da soma de verificação. O pseudocabeçalho contém os endereços IP de origem e destino 
e o tamanho do datagrama IP permitindo assim a detecção de adulteração desses campos ou a entrega de um pacote 
a um endereço incorreto. 

criptografia de chave pública Qualquer um dos diversos algoritmos de criptografia (por exemplo, RSA), em que cada 
participante possui uma chave privada (não compartilhada com outros) e uma chave pública (disponível para todos). 
Uma mensagem segura é enviada a um usuário cifrando-se os dados com a chave pública do usuário; a posse da chave 
privada é necessária para a decifração da mensagem, e, portanto, apenas o receptor pode lê-la. 

QoS Quality of Service (Qualidade de Serviço). Garantias de entrega de pacote fornecidas por uma arquitetura de rede. 
Normalmente, isso está relacionado a garantias de desempenho, como largura de banda e atraso. A Internet oferece 
um serviço de entrega de melhor esforço, significando que todos os esforços são feitos para entregar um pacote, mas 
a entrega não é garantida. 

RED Random Early Detection (Detecção Aleatória Antecipada). Uma política de enfileiramento para roteadores em que, 
quando prevê-se um congestionamento, os pacotes são descartados aleatoriamente para alertar os emissores para 
que eles diminuam sua velocidade. 
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ponto de encontro (Rendezvous Point). Um roteador utilizado pelo PIM para permitir que os receptores descubram 
quem são os emissores. 

repetidor Um dispositivo que propaga sinais elétricos de um cabo Ethernet para outro. Pode haver no máximo dois 
repetidores entre dois hosts quaisquer em uma Ethernet. Repetidores encaminham sinais, enquanto pontes encami- 
nham quadros, e roteadores/switches encaminham pacotes. 

REST Representational State Transfer (Transferência de Estado Representacional). Uma técnica para a criação de Web 
Services, que utiliza http como protocolo de aplicação genérico. 

RFC Request for Comments (Pedido de Comentários). Relatórios da Internet que contêm, entre outras coisas, especificações 
para protocolos, como TCP e IP 

RIP Routing Information Protocol (Protocolo de Informações de Roteamento). Um protocolo de roteamento intradomínio, 
fornecido com o Berkeley Unix. Cada roteador executando RIP monta dinamicamente sua tabela de encaminhamento 
com base em um algoritmo por vetor de distâncias. 

roteador Um nó de rede conectado a duas ou mais redes, encaminhando pacotes de uma rede para outra. Compare com 
ponte, repetidor e switch. 

roteamento O processo pelo qual os nós trocam informações topológicas para montar tabelas de encaminhamento 
corretas. Ver encaminhamento, estado do enlace e vetor de distâncias. 

tabela de roteamento Ver tabela de encaminhamento. 

RPB Reverse Path Broadcast (Broadcast pelo Caminho Reverso). Uma técnica utilizada para eliminar pacotes de broadcast 
duplicados. 

RPC Remote Procedure Call (Chamada de Procedimento Remoto). Protocolo de transporte síncrono do tipo solicitação /resposta, 
usado em muitas interações cliente/servidor. 

RPR Resilient Packet Ring (anel de pacotes resiliente). Um tipo de rede em anel que é usado principalmente em redes 
metropolitanas. Ver 802.17. 

RSA Um algoritmo de criptografia de chave pública que recebeu o nome de seus inventores Rivest, Shamir e Adleman. 

RSVP Resource Reservation Protocol (Protocolo de Reserva de Recursos). Um protocolo para reservar recursos na rede. O 
RSVP utiliza o conceito de estado soft nos roteadores e coloca a responsabilidade por fazer reservas sobre os receptores, 
e não sobre os emissores. 

RTCP Real-time Transport Control Protocol (Protocolo de Controle de Transporte em Tempo Real). Protocolo de controle 
associado ao RTP 

RTP Real-time Transport Protocol (Protocolo de Transporte em Tempo Real). Um protocolo fim a fim, usado por aplicações 
multimídia que possuem restrições de tempo real. 

RTT Round-Trip Time (tempo de ida e volta). O tempo gasto para um bit de informações se propagar de uma ponta de 
um enlace ou canal até a outra ponta e voltar; em outras palavras, o dobro da latência do canal. 

SAN System Area Network (Rede de área de sistema). Uma rede cobre componentes de um sistema computacional (por 
exemplo, monitor, câmera, disco). Às vezes significa Storage Area Network (rede da área de armazenamento) e inclui 
interfaces como HiPPI (High-Performance Parallel Interface) e Fibre Channel. Compare com LAN, MAN e WAN. 

schema (esquema) Uma especificação de como estruturar e interpretar um conjunto de dados. Esquemas são definidos 
para documentos XML. 

embaralhamento O processo de realizar uma operação XOR de um sinal com um fluxo de bits pseudoaleatório antes 
da transmissão, de modo a causar transições de sinal suficientes para permitir a recuperação do relógio. O embara- 
lhamento é usado no SONET. 

SDP Session Description Protocol (Protocolo de Descrição da Sessão). Um protocolo da camada de aplicação usado para 
obter informações a respeito dos canais de áudio/vídeo disponíveis. Ele informa o nome e a finalidade da sessão, 
horários de início e fim da sessão, os tipos de mídia (por exemplo, áudio, vídeo) que compõem a sessão, e informações 
detalhadas necessárias para receber a sessão (por exemplo, o endereço de multicast, protocolo de transporte e números 
de porta a serem usados). 

Secure Hash Algorithm (SHA) Uma família de algoritmos de hash criptográficos. 

segmento Um pacote TCP Um segmento contém uma parte do fluxo de bytes que está sendo enviado por meio 
do TCP 

SELECT Um protocolo de demultiplexação síncrona, usado para montar um protocolo RPC (Remote Procedure Call). 

semáforo Uma variável utilizada para dar suporte à sincronização de processos. Normalmente, um processo é bloqueado 
em um semáforo enquanto espera que algum outro processo sinalize o semáforo de que o processamento pode 
continuar. 

servidor O provedor de um serviço em um sistema distribuído do tipo cliente/servidor. 

sinalização No nível físico, indica a transmissão de um sinal por algum meio físico. No ATM, a sinalização refere-se ao 
processo de estabelecimento de um circuito virtual. 

síndrome da janela boba Uma condição que ocorre no TCP a qual pode surgir se, toda vez que o receptor abrir sua janela 
de recepção por uma pequena quantidade, o emissor enviar um segmento pequeno para preencher a janela. Como 
resultado, haverá muitos segmentos pequenos e um uso ineficaz da largura de banda. 

SIP Session Initiation Protocol (Protocolo de Iniciação de Sessão). Um protocolo da camada de aplicação, usado em 
aplicações multimídia. Ele determina o dispositivo correto com o qual alguém deve se comunicar para alcançar 
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determinado usuário, determina se o usuário deseja ou pode participar em uma comunicação em particular, 
determina a escolha de mídia e esquema de codificação a usar, e estabelece os parâmetros da sessão (por exemplo, 
os números de porta). 

janela deslizante Um algoritmo que permite que o emissor transmita vários pacotes (até o tamanho da janela) antes 
de receber uma confirmação. Quando as confirmações são retornadas para esses pacotes dentro da janela em que 
foram enviados inicialmente, a janela “desliza” e mais pacotes podem ser enviados. O algoritmo de janela deslizante 
combina entrega confiável com uma vazão alta. Ver ARQ. 

partida lenta Um algoritmo de prevenção de congestionamento do TCP que tenta controlar a velocidade de envio dos 
segmentos de saída. Para cada ACK retornado, dois pacotes adicionais são enviados, resultando em um aumento 
exponencial no número de segmentos pendentes. 

SMTP Simple Mail Transfer Protocol (Protocolo Simples de Transferência de Correio). O protocolo de correio eletrônico 
(e-mail) da Internet. Ver 822. 

SNA System Network Architecture. A arquitetura de rede própria da IBM. 

SNMP Simple Network Management Protocol (Protocolo Simples de Gerenciamento de Rede). Um protocolo da Internet 
que permite a monitoração de hosts, redes e roteadores. 

SOAP Um componente do arcabouço de Web Services para especificar e implementar protocolos de aplicação. 

socket Uma abstração fornecida pelo Unix e outros sistemas operacionais, que fornece a interface de programação de 
aplicações (API) para o TCP/IP 

estado soft Informações relacionadas à conexão, armazenadas em um roteador, que ficam em cache por um período 
de tempo limitado, em vez de serem estabelecidas explicitamente (e exigindo um término explícito) por meio da 
configuração de uma conexão. 

SONET Synchronous Optical Network (Rede Óptica Síncrona). Um padrão de enquadramento baseado em relógio, para a 
transmissão digital por fibra óptica. Ele define o modo como as companhias telefônicas transmitem dados por redes 
ópticas. 

roteamento na origem Decisões de roteamento tomadas na origem, antes que o pacote seja enviado. A rota consiste na 
lista de nós que o pacote deverá atravessar em seu percurso até o destino. 

multicast específico da origem Um modo de multicast em que um grupo só pode ter um único emissor. 

multicast em modo esparso Um modo usado no PIM (Protocol Independent Multicast, ou Multicast Independente de 
Protocolo) quando relativamente poucos hosts ou roteadores precisam receber dados de multicast para um certo 
grupo. 

horizonte dividido Um método de remover laços de roteamento em um algoritmo de roteamento por vetor de distâncias. 
Quando um nó envia uma atualização de roteamento aos seus vizinhos, ele não envia as rotas que descobriu de cada 
um deles de volta. O horizonte dividido é usado com o envenenamento reverso. 

espalhamento espectral Técnica de codificação que envolve espalhar um sinal por uma frequência mais larga do que o 
necessário, a fim de reduzir o impacto da interferência. 

SSL Secure Socket Layer. Uma camada de protocolo que é executada em cima do TCP para oferecer autenticação e cifração 
de conexões. Também conhecido como Transport Layer Security (TI.S). 

multiplexação estatística Multiplexação baseada em demanda de várias origens de dados por um enlace ou canal 
compartilhado. 

parar e esperar Um algoritmo de transmissão confiável, em que o emissor transmite um pacote e espera uma confirmação 
antes de enviar o próximo pacote. Compare com janela deslizante e canais lógicos concorrentes. Ver também ARQ. 

STS Synchronous Transport Signal (Sinal de Transporte Síncrono). O prefixo usado para várias taxas de transmissão SONET. 
Por exemplo, STS-1 refere-se ao padrão SONET para transmissão a 51,84 Mbps. 

sub-rede O uso de um único endereço de rede IP para indicar várias redes físicas. Os roteadores dentro da sub-rede 
utilizam uma máscara de sub-rede para descobrir a rede física à qual um pacote deve ser encaminhado. A sub- 
-rede efetivamente introduz um terceiro nível ao endereçamento IP hierárquico de dois níveis. 

SunRPC Protocolo de chamada de procedimento remoto, desenvolvido pela Sun Microsystems. O SunRPC é utilizado 
para dar suporte ao NFS. Ver também ONC. 

switch Um nó da rede que encaminha pacotes de entradas para saídas, com base nas informações de cabeçalho em cada 
pacote. Difere de um roteador principalmente porque em geral não interconecta redes de tipos diferentes. 

malha de comutação O componente de um switch que direciona pacotes de suas entradas para as saídas corretas. 

T1 Um serviço padrão da companhia telefônica, igual a 24 circuitos ISDN, ou 1,544 Mbps. Também chamado DS1. 

T3 Um serviço padrão da companhia telefônica, igual a 24 circuitos T1, ou 44,736 Mbps. Também chamado DS3. 

TCP Transmission Control Protocol (Protocolo de Controle de Transmissão). Protocolo de transporte orientado à conexão, 
usado na arquitetura Internet. O TCP oferece um serviço confiável de entrega de fluxo de bytes. 

TDMA Time Division Multiple Access (Acesso Múltiplo por Divisão de Tempo). Uma forma de multiplexação usada em 
redes de celulares sem fios. Também é o nome de um padrão sem fios em particular. 

Telnet Protocolo de acesso a terminal remoto da arquitetura Internet. O Telnet permite ao usuário interagir com um 
sistema remoto como se o seu terminal estivesse conectado diretamente a essa máquina. 

vazão A taxa observada em que os dados são enviados através de um canal. O termo normalmente é usado para indicar 
o mesmo que largura de banda. 
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TLS Transport Layer Security. Serviços de segurança que podem ser dispostos em cima de um protocolo de transporte, 
como TCP Normalmente, é usado pelo HTTP para realizar transações seguras na World Wide Web. Derivado de SSL. 

balde de fichas Um modo de caracterizar ou policiar a largura de banda usada por um fluxo. Conceitualmente, os 
processos acumulam fichas com o tempo, e eles precisam gastar uma ficha para transmitir um byte de dados e depois 
precisam interromper o envio quando não possuem mais fichas. Assim, a largura de banda geral é limitada, com a 
acomodação de algum tráfego em rajada. 

Token ring Uma tecnologia de rede física em que os hosts estão conectados em um anel. Um token (ficha, correspondente 
a uma sequência padrão de bits) circula em torno do anel. Determinado nó precisa possuir o token antes que possa 
transmitir. 802.5 e FDDI (Fiber Distributed Data Interface) são exemplos de redes token ring. 

protocolo de transporte Um protocolo fim a fim, permitindo a comunicação entre processos em hosts diferentes. O TCP 
é o exemplo canônico. 

TTL (time-to-live) Tempo de vida. Normalmente, uma medida do número de saltos (roteadores) que um datagrama IP 
pode visitar antes de ser descartado. 

tunelamento Encapsulamento de um pacote usando um protocolo que opera na mesma camada do pacote. Por exemplo, 
para implementar o MBone, os pacotes de multicast IP são encapsulados dentro de pacotes de unicast IP para tunelar 
através da Internet. O tunelamento também será usando durante a transição do IPv4 para o IPv6. 

paridade bidimensional Um esquema de paridade em que os bytes são conceitualmente empilhados como uma matriz, 
e a paridade é calculada para linhas e colunas. 

Tymnet Uma antiga rede em que uma abstração de circuito virtual era mantida ao longo de um conjunto de roteado- 
res. 

UBR Unspecified Bit Rate (taxa de bits não especificada). A classe de serviço “sem enfeites” do ATM, oferecendo a entrega 
de células pelo melhor esforço. Compare com ABR, CBR e VBR. 

UDP User Datagram Protocol (Protocolo de Datagramas de Usuário). Protocolo de transporte da arquitetura Internet, 
que oferece um serviço de datagramas sem conexões para processos no nível de aplicação. 

UMTS Universal Mobile Telecommunications System (Sistema de Telecomunicações Móveis Universal). Padrão de telefonia 
celular sem fios baseado no Acesso Múltiplo por Divisão de Código (Code Division Multiple Access - CDMA) de banda 
larga, que oferece taxas de dados relativamente altas. 

unicast Envio de um pacote a um único host de destino. Compare com broadcast e multicast. 

URI Uniform Resource Identifier (Identificador de Recursos Uniforme). Uma generalização do URL. Usado, por exemplo, 
em conjunto com o Protocolo de Iniciação de Sessão (Session Initiation Protocol — SIP) para configurar sessões de 
multimídia. 

URL Uniform Resource Locator (Localizador de Recursos Uniforme). Uma cadeia de caracteres de texto usada para 
identificar a localização de recursos da Internet. Um URL típico se parece com http://www.cisco.com. Nesse URL, http 
é o protocolo utilizado para acessar o recurso localizado no host www.cisco.com. 

vat Ferramenta de audioconferência usada na Internet, que é executada em cima do RTP 

VBR Variable Bit Rate (taxa variável de bits). Uma das classes de serviço do ATM, voltada para aplicações com requisitos 
de largura de banda que variam com o tempo, como vídeo comprimido. Compare com ABR, CBRe UBR. 

VCI Virtual Circuit Identifier Identificador de Circuito Virtual). Um identificador no cabeçalho de um pacote, que é usado 
para a comutação de circuitos virtuais. No caso do ATM, o VPI e o VCI juntos identificam a conexão fim a fim. 

vic ferramenta de videoconferência baseada no Unix, que utiliza RTP 

circuito virtual A abstração fornecida pelas redes orientadas à conexão, como ATM. Mensagens normalmente precisam 
ser trocadas entre os participantes para estabelecer um circuito virtual (e talvez alocar recursos ao circuito) antes que 
os dados possam ser enviados. Compare com datagrama. 

relógio virtual Um modelo de serviço que permite que a origem reserve recursos nos roteadores usando uma descrição 
de suas necessidades em termos de taxa de envio. O relógio virtual vai além do serviço de entrega de melhor esforço 
da Internet atual. 

VPI Virtual Path Identifier (Identificador de Caminho Virtual). Um campo de 8 ou 12 bits no cabeçalho ATM. O VPI pode 
ser usado para ocultar várias conexões virtuais através de uma rede dentro de um único “caminho” virtual, diminuindo, 
assim, a quantidade de estado de conexão que os switches precisam manter. Ver também VCI. 

VPN Virtual Private Network (Rede Privada Virtual). Uma rede lógica disposta em cima de alguma rede existente. Por 
exemplo, uma empresa com instalações no mundo inteiro pode montar uma rede virtual em cima da Internet, em 
vez de alugar linhas entre cada instalação. 

WAN Wide Area Network (rede de longa distância). Qualquer tecnologia de rede física que seja capaz de cobrir longas 
distâncias (por exemplo, atravessando o país). Compare com SAN, LAN e MAN. 

porta bem conhecida Um número de porta que, por convenção, é dedicado para uso por determinado serviço. Por exemplo, 
o servidor de nomes de domínio (DNS) em cada host recebe mensagens pela porta UDP e TCP bem conhecida 53. 

WFQ Weighted Fair Queuing (enfileiramento justo ponderado). Uma variação do enfileiramento justo, em que cada fluxo 
pode receber uma proporção diferente da capacidade da rede. 

WSDL Web Services Description Language (Linguagem de Descrição de Web Services). Um componente do arcabouço de 
Web Services para especificar e implementar protocolos de aplicação. 

WWW World Wide Web. Um serviço de informação de hipermídia na Internet. 
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X.25 O protocolo de comutação de pacotes padronizados pela TTU. 

X.400 O padrão de correio eletrônico da ITU. O equivalente ao SMTP (Simple Mail Transfer Protocol) na arquitetura 
Internet. 

X.500 O padrão de serviços de diretório da ITU, que define um serviço de nomes baseado em atributos. 

X.509 Um padrão ITU para certificados digitais. 

XDR External Data Representation (Representação Externa de Dados). Padrão da Sun Microsystems para estruturas de 
dados independentes da máquina. Compare com ASN.1 e NDR. 

XML Extensible Markup Language (Linguagem de Marcação Extensível). Define uma sintaxe para descrever dados que 
possam ser passados entre aplicações da Internet. 

XSD XML Schema Definition (Definição de Esquema XML). Uma linguagem de esquema para definir o formato e a inter- 
pretação dos objetos XML. 

zona Uma partição da hierarquia de nomes de domínio, correspondente a uma autoridade administrativa que é 
responsável por essa parte da hierarquia. Cada zona precisa ter pelo menos dois servidores de nomes para tratar as 
solicitações de DNS para a zona. 
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